[redhat-lspp] Xinetd patches for selinux context configuration

James Antill jantill at redhat.com
Wed Nov 29 19:04:17 UTC 2006


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

...I'm also having problems working out what to call
security_compute_create() with. For instance I assumed this was right:

        security_context_t ret = NULL;
        if (security_compute_create("user_u:system_r:inetd_t:SystemLow-SystemHigh", "user_u:system_r:fingerd_exec_t", PROCESS__DYNTRANSITION, &ret) != -1)
                puts(ret);

...but it returns -1.
 It also has weird results is I pass other things in (role likes to
change to object_r and MLS goes missing).
 One simple fix is to have the full context specified in the config.
file, as it was in my first attempt ... but then take the MLS from the
other end, if it passes a CONTEXT__CONTAINS check. Much like the
crond/PAM changes.


-- 
James Antill - <james.antill at redhat.com>
setsockopt(fd, IPPROTO_TCP, TCP_CONGESTION, ...);
setsockopt(fd, IPPROTO_TCP, TCP_DEFER_ACCEPT, ...);
setsockopt(fd, SOL_SOCKET,  SO_ATTACH_FILTER, ...);

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/redhat-lspp/attachments/20061129/e45c7c46/attachment.sig>


More information about the redhat-lspp mailing list