Several policy questions

[Stephen Smalley]

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 at oss.tresys.com is a good place to ask such questions as well.

-- 
Stephen Smalley
National Security Agency