On Tue, 2009-03-10 at 18:26 -0700, Brian Ginn wrote:
I have an application that consists of four different programs that
all talk to each other via TCP sockets… Similar to the diagram:
+---------+
+-------| ServerA |------+
| +---------+ |
| | |
+----------------+ | +---------+
| UserApp Client |---|-----| ServerB |
+----------------+ | +---------+
| | |
| | |
| +--------+ |
+-------| Logger |------+
+--------+
The ServerA, ServerB, and Logger all run from xinetd.
The "UserApp Client" is the only program directly executed via the
user.
All programs read from a common settings file in /etc.
With Fedora Core 9, I've used the polgengui to create initial policies
for the four programs.
Then since they share the settings file, I edited the definitions so
that configuration file is not specific to any one of the programs.
They all need to share port information, so I added require
{ myservera_port_t; myserverb_port_t; mylogger_port_t } statements to
each .te file.
That seems to work on FC9, but on RedHat EL 5.2, when attempting to
load myservera, it complains:
/usr/sbin/semodule -i myservera.pp
libsepol.print_missing_requirements: myservera's global requirements
were not met: type/attribute myserverb_port_t
libsemanage.semanage_link_sandbox: Link packages failed
/usr/sbin/semodule: Failed!
Attempting to load myserverB first ends up with the same complaint
about the serverA's port_t being undefined.
That is to be expected since they have a mutual dependency. You should
get the same error on FC9 if you are installing one of those modules on
a clean system that doesn't already have the other modules installed.
You could overcome it by passing all of the modules at once to semodule,
e.g.
semodule -i myservera.pp -i myserverb.pp -i mylogger.pp
or depending on the version of semodule, just
semodule -i myservera.pp myserverb.pp mylogger.pp
so that they can be inserted in a single transaction, enabling the
mutual dependencies to be resolved.
I had kept the .te files for the four programs separate… but this
message makes me think that maybe I need to combine them. Is that
necessary? Or is there a way to pre-define the ports before the
"require from somewhere else" statement?
You can keep them separate using the above technique or by refactoring
them as Dominick suggested, but I'm not sure why you would do so since
they form a single logical application. Will you ever want to install
one without the others?
For my four programs, should I have four distinct policy_module
statements?
Only if their policies live in separate modules. A single module may
contain any number of distinct domains, so you don't need a separate
module per domain if that is your question.
Is it possible to have multiple policy_module statements in the
same .te file?
Not presently, no.
Also, I seem to be having domain transfer problems.
I added this following code to each .te file:
domain_auto_trans(unconfined_t, myapp_exec_t, myapp_t )
allow unconfined_t myapp_t:fd use;
allow myapp_t unconfined_t:fifo_file rw_file_perms;
allow myapp_t unconfined_t:process sigchld;
Try to use refpolicy interfaces when possible.
As Dominick noted, you are missing a role declaration for myapp_t here
that could prevent the transition - that should have triggered a
SELINUX_ERR message in the audit log.
however, each process still runs as follows:
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 32504 pts/4
00:00:00 myapp
unconfined_u:system_r:inetd_child_t:s0-s0:c0.c1023 32508 ? 00:00:00
myserverb
unconfined_u:system_r:inetd_child_t:s0-s0:c0.c1023 32512 ? 00:00:00
mylogger
For the inetd daemons, is this something I should try to fix, or is
unconfined_u:system_r:inetd_child_t "secure enough"?
I'd recommend creating your own domain.
refpolicy(a)oss.tresys.com is a good place to ask such questions as well.
--
Stephen Smalley
National Security Agency