From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <451C3A37.8080509@us.ibm.com> Date: Thu, 28 Sep 2006 16:10:15 -0500 From: Michael C Thompson MIME-Version: 1.0 To: Stephen Smalley CC: Karl MacMillan , Joshua Brindle , Darrel Goeddel , Steve Grubb , SE Linux Subject: newrole - adding capabilities for polyinstantiation References: <451AEC39.2090409@us.ibm.com> <1159450384.11489.5.camel@moss-spartans.epoch.ncsc.mil> In-Reply-To: <1159450384.11489.5.camel@moss-spartans.epoch.ncsc.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov Stephen Smalley wrote: > On Wed, 2006-09-27 at 16:25 -0500, Michael C Thompson wrote: >> Hey Stephen, >> >> It looks like I will be taking over the newrole work that Janak was doing. > > Ok, good. Please keep discussion on list. Also there was discussion of > needing more auditing from newrole on redhat-lspp. Copying the selinux list on this reply to continue the discussion. >> After reading the thread, it seems like Janak's patches were getting >> close, but quite a few ideas were thrown out there, namely: >> >> 1) Have newrole be non-suid by default, and require the LSPP >> configuration package to enable its suid status (which would then enable >> the capabilities) >> >> 2) Have newrole be suid all of the time. >> >> 3) Have newrole determine if namespace is used for the configuration, >> which would then determine if the caps need to be loaded or not. >> >> Do you know if there was any decision on the path to take that I am >> unable to find on the mailing list? > > I think (2) is unacceptable (the real issue is not whether it is suid > per se, but whether it retains powerful capabilities like CAP_SYS_ADMIN > - it is already suid for the earlier audit support, but drops everything > but CAP_AUDIT_WRITE and reverts to the caller's uid upon startup). With Janak's patch, there is no differentiation between the capabilities needed to polyinstantiate and the capabilities to audit. Is there a desire to audit outside of an LSPP environment? If so, then I will address this issue in the patch (I see AUDIT being a requirement of LSPP, so there is a clear dependence chain). There is also the issue which Russel Coker brought up which is that pam_namespace is valuable to people outside an LSPP environment. Should this future work take that into account? > I don't know how to do (3) cleanly, as it seems to violate PAM > encapsulation. > > (1) addresses the concern for non-LSPP users, but doesn't fully address > my concerns about the additional risk to LSPP users. One obvious issue > is that drop_capabilities() currently also resets to the caller's uid, > which Janak's patches do not change. Which I think means that any > directories and files created by pam_namespace will initially be > assigned the caller's uid, and potentially exposed to tampering by > processes in the caller's uid. SELinux policy might prevent such > tampering, but it bears investigating. Likewise, this means that the > newrole process itself runs in the caller's uid and might be exposed to > interference by the caller in some forms, although I would expect that > SELinux would block that as long as newrole is running in a different > domain. I will take some time and look at this further. > We also need to consider whether more of the guidelines in e.g. the > Secure Programming HOWTO or the kinds of safeguards implemented > in /bin/su should be applied to newrole when it is suid. Historically, > newrole wasn't viewed as an especially privileged program, since it > wasn't suid originally and since the user-role authorizations were > actually enforced by the kernel, not by newrole. Thus it wasn't written > to be as paranoid about the caller as /bin/su is. Will look at this as well. Thanks, Mike -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.