On 11/30/2012 6:02 AM, David Quigley wrote: There are times when living by the correct ocean makes life so much easier. Thanks all for the early morning brain work. > On 11/30/2012 08:50, Stephen Smalley wrote: >> On 11/30/2012 08:35 AM, David Quigley wrote: >>> On 11/30/2012 08:28, Stephen Smalley wrote: >>>> On 11/30/2012 08:17 AM, David Quigley wrote: >>>>> On 11/30/2012 07:57, David Quigley wrote: >>>>>> On 11/30/2012 07:14, J. Bruce Fields wrote: >>>>>>> On Thu, Nov 29, 2012 at 09:02:49PM -0500, David Quigley wrote: >>>>>>>> On 11/29/2012 20:50, Casey Schaufler wrote: >>>>>>>> >On 11/29/2012 4:46 PM, David Quigley wrote: >>>>>>>> >>On 11/29/2012 19:34, Casey Schaufler wrote: >>>>>>>> >... Whole bunch snipped ... >> >> Looks like Smack requires CAP_MAC_ADMIN in order to set Smack >> attributes on a file at all. So nfsd would require that capability >> for Smack. I think this means however that setting Smack labels on >> NFS files won't work in any case where root is squashed, which seems >> unfortunate. I'm building a kernel with CAP_MAC_ADMIN set for nfsd. I am reasonably sure that this will get me past the current issue. As far as a squashed root goes, well, doing things that the security policy doesn't allow requires privilege. > > I'll leave that problem to Casey to figure out. However it seems to me > that regardless of Labeled NFS Casey should have problems with the NFS > server not being able to serve up files that are dominated by floor. I > wonder if he has every tried NFSv4 on a SMACK enabled server before. > It may have just worked because all files implicitly get labeled floor. CAP_MAC_OVERRIDE, which nfsd does have, is sufficient for reading and writing files. A Smack enabled server is able to serve to Smack and Smackless clients, but of course all label enforcement is lost. Thus it will "work", but it will be bad. I haven't used NFS much lately, in part because of the lack of labeling and the security issues inherent in serving labeled files to clueless clients. > >> >> On the SELinux side, we don't require CAP_MAC_ADMIN to set the >> SELinux attribute on a file in the normal case, only when the SELinux >> attribute is not known to the security policy yet. So granting >> CAP_MAC_ADMIN there means that a client will be able to set security >> contexts on files that are unknown to the server. I guess that might >> even be desirable in some instances where client and server policy are >> different. We do have the option of denying mac_admin permission in >> policy for nfsd (kernel_t?), in which case we would block such >> attempts to set unknown contexts but would still support setting of >> known security contexts. >> >> So I think it is workable, albeit a bit confusing. > > Yea it is unfortunate that we have to go mucking around in capability > land but it seems that adding CAP_MAC_ADMIN should be fine and we can > deal with it in policy if we like. Worst case we could add a security_set_nfsd_capabilities hook. Maybe make the capability set an export option? > > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to > majordomo@xxxxxxxxxxxxx with > the words "unsubscribe selinux" without quotes as the message. > -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
