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 -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
