Re: Labeled NFS [v5]

[Casey Schaufler <casey@schaufler-ca.com>]

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@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
>