Re: RFC: make labeled NFS opt-in

[Andy Adamson <androsadamson@gmail.com>]

On Thu, Jan 12, 2017 at 11:10 AM, J. Bruce Fields <bfields@fieldses.org> wrote:
> On Thu, Jan 12, 2017 at 10:29:14AM -0500, Andy Adamson wrote:
>> NFSv4.2 labeled NFS provides 'guest mode' Mandatory Access Control
>> (MAC) where the client can enforce labeling and store a label on the
>> server, but the server itself does not enforce the same MAC as the
>> client because the client request thread label is unknown to the
>> server. RPCSEC_GSS version 3 label assertions asserts the client
>> thread label on the NFSD thread handling the request, and so along
>> with LNFS provides Full Mode MAC.
>>
>> AFAICS the only time we want GSS3 label assertions is if LNFS is
>> enabled.  Does this sound right to you? If so, I will use this new per
>> export LNFS option to determine when GSS3 label assertions are
>> enabled.
>
> How do you disable or enable this on the server side?

In nfsd_setuser, if the rq_authop has the new set_label operation, and
selinux_is_enabled() then the label is asserted.

>
> I haven't been following the GSS3 development well, apologies.  So I
> guess you must do something like:
>
>         1. decode the GSS3 stuff in the RPC layer and store the
>         resulting subject label somewhere like rqstp->rq_cred.
>         2. in nfsd_setuser, set the nfsd thread's label to the label
>         stored in rq_cred.


Yes, I do both of those tasks.

>
> You probably need to have the processing in step 1 enabled all the time,
> because you don't know which export you're going to be dealing with yet
> at that point.

Yes.

>
> By step 2 you have the export.  So I guess you'd use the export option
> to decide whether to silently ignore the label, or apply it to the nfsd
> thread?

yes.

>
> That might make sense.

Good! That is easy to add and is what I am thinking.

I'm building the gss prototype against your latest nfsd-next. Once I
test it, i'll send in version 4.

-->Andy

>
> --b.