[redhat-lspp] Xinetd patches for selinux context configuration

[Stephen Smalley]

On Wed, 2006-11-29 at 14:04 -0500, James Antill wrote:
> On Wed, 2006-11-29 at 10:31 -0500, Stephen Smalley wrote:
> > 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.
> 
>  Ok, I assume you still also want the MLS range to be configurably bound
> as in:
> 
> http://www.redhat.com/archives/redhat-lspp/2005-September/msg00125.html

Yes, although one might be able to handle that in the labeled networking
code itself, by rejecting packets with labels outside of the client
host's authorized range before they are ever received by userspace.

> ...I'm also having problems working out what to call
> security_compute_create() with.

See the runcon source in coreutils or rpm_execcon() in libselinux.

>  For instance I assumed this was right:
> 
>         security_context_t ret = NULL;
>         if (security_compute_create("user_u:system_r:inetd_t:SystemLow-SystemHigh",

Correct - the current context of the subject.

>  "user_u:system_r:fingerd_exec_t",

Not quite - this should be an object context; you should have used
object_r above.

>  PROCESS__DYNTRANSITION,

Completely wrong - this should be a security class value, not a
permission value.  In particular, SECCLASS_PROCESS.

>  &ret) != -1)

< 0 is more general.

>                 puts(ret);
> 
> ...but it returns -1.

That's because the inputs were invalid.

-- 
Stephen Smalley
National Security Agency