[redhat-lspp] Xinetd patches for selinux context configuration

[Stephen Smalley]

On Wed, 2006-11-29 at 08:17 -0500, Paul Moore wrote:
> 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.

The above sounds correct.  With regard to the "race", if the binary's
type has changed since #3, then the execve should fail because the new
domain computed by #4 will lack entrypoint permission to the new file
type.

-- 
Stephen Smalley
National Security Agency