[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-nfs
Subject:    Re: Labeled NFS [v5]
From:       David Quigley <dpquigl () davequigley ! com>
Date:       2012-11-30 16:59:12
Message-ID: dd7dc9e3fcd4fe2ddc3a0678c6377c4b () countercultured ! net
[Download RAW message or body]

On 11/30/2012 11:55, J. Bruce Fields wrote:
> On Fri, Nov 30, 2012 at 08:50:55AM -0500, Stephen Smalley wrote:
>> 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.
>
> Note (as you probably know) this first pass at labeled NFS only lets 
> us
> label files, not rpc calls--if we want the server to know who's doing
> something (beyond the information the rpc headers already carry), 
> we'll
> need to implement rpcsec_gss v3, and that's a project for another 
> day.
>
> I've been assuming that makes server-side enforcement less useful for
> now.
>
> --b.

Ideally what will happen is that when we get RPCSECGSSv3 in we'll set 
the security context in the same place that we set uid and gid for the 
process in the auth code. Until then you're right server side 
enforcement really isn't possible because we have whatever context the 
kernel gives to the thread being our security context. In the SELinux 
case this is the all powerful kernel_t in the smack case its the floor 
context.

Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]