Re: Labeled NFS [v5]

[David Quigley <dpquigl@davequigley.com>]

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:
>> >>>I would think that were it not for the case that access is denied
>> >>>and I get an audit record for nfsd that reports a subject
>> >>>label of "_"
>> >>>(which is correct for nfsd but not the process attempting
>> >>>access) and
>> >>>an object label of "WhooHoo", which is correct. The server side
>> >>>looks like it might be working right, given the information that 
>> it
>> >>>has.
>> >>>
>> >>
>> >>Ok so this is the problem. nfsd is a kernel thread I believe. In
>> >>SELinux land it has the type kernel_t which is all powerful. We
>> >>don't
>> >>have client label transport yet (That requires RPCSECGSSv3). Is
>> >>there
>> >>a way you can have that kernel thread running as a type that has
>> >>access to everything?
>> >
>> >That would be having CAP_MAC_ADMIN and CAP_MAC_OVERRIDE in 
>> Smackese.
>> >Looking at /proc/<pid-of-nfsd>/status we see CapEff of fff...fff
>> >which
>> >is to say, all capabilities.
>> >
>>
>> Hmm thats interesting then. You could try using rpcdebug -m nfsd to
>> turn on some of the debugging to look around the internals and
>> figure out whats going on. If you pass -v it will give you all of
>> the potential flags.
>>
>> >
>> >>I think that is the current problem. Which makes perfect sense. If
>> >>your kernel threads don't get started with max privilege then the
>> >>server would be denied access on all of the file attributes and
>> >>wouldn't be able to ship it over the wire properly.
>> >
>> >OK. I haven't had to do anything with kernel threads so far.
>> >Where is NFS setting these up? Poking around fs/nfsd looks like
>> >the place, but I haven't seen anything there that makes it look
>> >like they would be running without capabilities. Clearly, that's
>> >what I'm seeing. It looks as if the credential of nfsd does not
>> >match what /proc reports. Bother.
>> >
>>
>> I'm not entirely sure whats up either. If you want to look for the
>> NFSd threads they are in fs/nfsd/nfssvc.c. The main function starts
>> on line 487.
>
> I'm not following the discussion, but: maybe you want to look at
> fs/nfsd/auth.c:nfsd_setuser() ?  In particular, the
> cap_{drop/raise}_nfsd_set() calls at the end.
>
> --b.


I'm not as familiar with the capabilities code as Casey is so I'll 
leave this ball in his court. I think you are correct though and the 
problem is that NFSd is dropping and raising caps and we need to make 
sure that MAC_ADMIN and MAC_OVERRIDE is in there in the SMACK case.