[Labeled-nfs] Labeled RPC & NFS

[James Morris]

On Sun, 2 Dec 2007, Matthew N. Dodd wrote:

> > 
> > > > I assume that's just for prototyping purposes?  My understanding was
> > > > that we were going to do this via GSS.
> > > GSS adds nothing but additional complexity at this point.  The key changes
> > > here are the ones that change the various cred structures consumed by the
> > > RPC and NFS code.
> > 
> > Well, labeled NFS must work with existing GSS implementations, and it seems
> > that this scheme is incompatible with GSS as it is a distinct security
> > flavor of its own.
> 
> So a couple of potential issues.
> 
> The userland/kernel GSS protocol provides credential service on a per-UID
> basis.
> 
> The credential cache mechanism matches per UID.  (As did the auth_unix
> mechanism which is why I created a whole new auth_seclabel.)
> 
> In general the current RPC implementation seems poorly suited to MAC
> environments.
> 
> RPCSEC_GSS seems like a good idea, but the implementation isn't actually very
> extensible (in the way we need to be able to add additional fields to the
> credential.)

Ok, I don't disagree with the RPCSEC_GSS issues above, but I'm wondering 
if it's viable to prevent its use when MAC labeling is active.

I gather the expectation is that AUTH_SECLABEL would be used in 
conjunction with IPSec or other machine-based security.  I believe this 
can provide useful security if configured carefully, e.g. specify MAC 
policy on the client so that only trusted subjects have the ability to 
send traffic to the NFS port, to prevent forging of RPC messages (and thus 
MAC attributes); or even use labeled IPSec :-)

However, I think that end to end authentication is still highly desirable, 
so that stronger security measures such as hardware tokens and biometrics 
can be used to establish a security relationship directly between the end 
user and the server.

Let's say that someone manages to compromise a client machine via a kernel 
bug in the case of using machine-based security only.  They will then be 
able to forge any MAC credentials which the server will accept from that 
client machine.  This may include all possible MAC credentials.

If the system was instead using end to end security, then the immediate 
damage would be limited to forging MAC credentials of users only on the 
compromised system, and if using e.g. hardware tokens, then perhaps 
further limited to active sessions.

So, I think that admins will want the choice to use RPCSEC_GSS for end to 
end security, and that we thus need to find another way to convey the MAC 
credentials of users.


- James 
--
James Morris
<jmorris at namei.org>