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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
