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 'u...@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/
_______________________________________________
bblisa mailing list
[email protected]
http://www.bblisa.org/mailman/listinfo/bblisa
