[redhat-lspp] Xinetd patches for selinux context configuration

[Paul Moore]

On Wednesday 29 November 2006 2:06 am, James Antill wrote:
> On Wed, 2006-11-29 at 01:00 -0500, Paul Moore wrote:
> > I just took a quick look at the patch and I have to ask why you decided
> > to take the context from the xinetd config file instead of using
> > security_compute_create() as described in BZ #209379?  As it stands I
> > don't think the current approach of taking the full SELinux context (TE
> > and MLS label) from the config file solves the problem we are interested
> > in - multi-level network services via xinetd.
>
>  Ok, if that's the problem I'm not sure why we want any changes to the
> config. file. As I understand it from the above BZ, you have:
>
> user_u:system_r:inetd_t
>     = xinetd is running as this
> user_u:system_r:fingerd_exec_t
>     = in.fingerd on disk
> user_u:system_r:fingerd_t
>     = in.fingerd when run normally from xinetd
> user_u:system_r:unconfined_t:SystemLow-SystemHigh
>     = getpeercon()
>
> user_u:system_r:fingerd_t:SystemLow-SystemHigh
>     = What we want the in.fingerd to be running in, with ML networking

That's it exactly.  I don't think we want any changes to the config file, at 
least I don't see a need for any changes; I think all we want is a change to 
how xinetd operates when the "LABELED" flag is specified.

>  So we need to take the getfilecon() and getpeercon() and combine them
> somehow (the BZ says security_compute_create()[1]), and we might then
> need to move to fgetfilecon() / fexecve() to close the race :(.
>  Is the above right? If not what piece(s) of information need to come
> from the config. file?
>
> [1] I tried a few different calls with security_compute_create, and
> maybe I'm not using the right security class, but I can't get it to
> combine the TE and MLS correctly.

Granted I haven't actually tried any of this to verify that it works, but I 
suspect you would want to do the following (I'm also not the best person to 
ask about SELinux userspace calls so there may be better functions to use):

1. getpeercon() to determine the context of the remote
2. getcon() to determine the context of xinetd
3. getfilecon() to determine the context of the server's binary
4. Compute the context of the server's domain when run by xinetd using
   security_compute_create(), the contexts from #2 and #3, and the process
   class
5. Replace the MLS label from #4 with the MLS label from #1
6. setexeccon() with #5 to set the context for the server
7. Start the server

Yes, there is a race condition between steps #3 and #7 but in practice I don't 
think it will be a real issue as normal users should not have write/relabel 
access to any of the server's binaries on disk which means only the admin 
would have the ability to cause the race.

-- 
paul moore
linux security @ hp