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