Several policy questions

[Brian Ginn]

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.

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?

For my four programs, should I have four distinct policy_module statements?
Is it possible to have multiple policy_module statements in the same .te file?

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;
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"?
Any suggestions for getting the myapp domain transferred?

Thanks,
Brian

[Dominick Grift]

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.
>
> 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 could maybe declare your ports in a separate port module. Or you
could integrate your modules to the main selinux-policy packages.
> For my four programs, should I have four distinct policy_module
> statements?
>
> Is it possible to have multiple policy_module statements in the
> same .te file?
>
> 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 )

This would also require: role unconfined_r types myapp_t;
However please consider that the unconfined domain is designed to be
unrestricted. (it should not domain transition to unconfined domains)

One would use the confined user domains (if available)
> allow unconfined_t myapp_t:fd use;
>
> allow myapp_t unconfined_t:fifo_file rw_file_perms;
>
> allow myapp_t unconfined_t:process sigchld;
>
> 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

initd_daemons are declared this way:

inetd_tcp_service_domain(myserverb_t, myserverb_exec_t)
role system_r types myserverb_t;

This also takes care of domain transition
> For the inetd daemons, is this something I should try to fix, or is
> unconfined_u:system_r:inetd_child_t "secure enough"?
>
> Any suggestions for getting the myapp domain transferred?
>
> Thanks,
>
> Brian
>
> --
> fedora-selinux-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[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.

[e-mail] is a good place to ask such questions as well.