[BBLISA] Secure, authenticated file serving to untrusted clients

[Tom Metro]

Dean Anderson wrote:
> I thought the question was about using Selinux on a client machine
> with an untrusted root user.

Sure, but you made the reasonable assumption that it is a multi-user 
machine, where a root compromise has a consequence, and I made the 
assumption that the OP was talking about an individual's workstation. 
Either option is possible, though the latter is a bit more probable in a 
modern business environment.


Lets take another look at the original question:

Ben Eisenbraun wrote:
> I'm looking for a file serving method that lets me securely share
> files out  to clients with untrusted root users. I.e. if user home
> directories are on a read-write network volume, I want to stop root
> on a workstation from  doing:
> 
> rm -rf ~user
> 
> or
> 
> su - user
> rm -rf ~

With NFS < v4, you can foil "rm -rf ~user" with the 'root_squash' 
option, but it won't address the second case if the malicious user has 
root control of the workstation and creates a local account for 'user' 
with a UID matching 'user at server'.


> From what I understand of NFSv4, if I set it up to use kerberos, then
> I can do this, since only a user with a valid kerberos ticket will be
> able to access the files on the share.

According to the NFS v4 RFC, it actually supports several secure 
authentication protocols, one of which is Kerberos. Any of those ought 
to address both scenarios above (though the RFC notes that implementers 
are free to relax security for some operations to benefit performance). 
Specifically it says:

http://tools.ietf.org/html/rfc3530#section-16

16. Security Considerations

   NFS has historically used a model where, from an authentication
   perspective, the client was the entire machine, or at least the
   source IP address of the machine.  The NFS server relied on the NFS
   client to make the proper authentication of the end-user.  The NFS
   server in turn shared its files only to specific clients, as
   identified by the client's source IP address.  Given this model, the
   AUTH_SYS RPC security flavor simply identified the end-user using
   the client to the NFS server.  When processing NFS responses, the
   client ensured that the responses came from the same IP address and
   port number that the request was sent to.  While such a model is
   easy to implement and simple to deploy and use, it is certainly not
   a safe model.  Thus, NFSv4 mandates that implementations support a
   security model that uses end to end authentication, where an
   end-user on a client mutually authenticates (via cryptographic
   schemes that do not expose passwords or keys in the clear on the
   network) to a principal on an NFS server.  Consideration should also
   be given to the integrity and privacy of NFS requests and responses.
   The issues of end to end mutual authentication, integrity, and
   privacy are discussed as part of the section on "RPC and Security
   Flavor".

In short its saying that with v4 the trust relationship isn't 
established between machines, but instead with individual users, so if 
you don't have the credentials to authenticate as a user, you can't 
perform operations as that user on the server.

So what remains is the multi-user compromised machine scenario, where 
keys can be stolen and passphrases keylogged. But security 101 says you 
don't use an untrusted machine, and I don't think this was part of the 
OP's scenario.

Other v4 reference material:

(podcast) NFSv4, Spencer Shepler, Sun Microsystems
http://www.usenix.org/events/usenix05/tech/italks.html#nFSv4

NFS Version 4 Open Source Reference Implementation
http://www.citi.umich.edu/projects/nfsv4/


  -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/