Re: Labeled NFS [v5]

[David Quigley <dpquigl@davequigley.com>]

On 11/30/2012 11:21, Casey Schaufler wrote:
> 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.

Can we confirm that this problem doesn't manifest itself without a 
Labeled NFS kernel? Set the labels on the exported files properly and 
then just mount over NFSv4 and see what happens?


>
>
>>
>>>
>>> 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.
>>