[BBLISA] Secure, authenticated file serving to untrusted clients

[Dean Anderson]

Hi Tom,

On Sun, 19 Apr 2009, Tom Metro wrote:

> > Michael Sprague wrote:
> >> ...couldn't you use something like grsecurity or selinux to prevent
> >> even root from doing anything bad to the network attached storage?
> > 
> > "No, they won't help if root can't be trusted". The reason is that once
> > you have kernel loader privilege, you can alter the kernel to circumvent
> > whatever security has been added to it...
> 
> Your answer may be correct, but I'm not sure it is relevant in the 
> context of the original question.
> 
> If the original question is about providing access to a file system over 
> a network where the remote *clients* don't have a secure and trusted 
> root, then obtaining "kernel loader privilege" on the server is not 
> likely to happen.

I thought the question was about using Selinux on a client machine with
an untrusted root user.  Selinux won't save a client machine with an
untrusted root if that person can load kernel modules.  If another
person logs into that machine, the machine may be compromised despite
Selinux, and so their password and credential can also be compromised.

I don't know if you are familiar with athena workstations at MIT, but
I'd say they fall into the category of clients I'm talking about.  They
run linux and use AFS to get to home directories. There are some
machinations to keep people from getting root, but its probably dubious.  
The old vaxstations (with athena bsd) that athena used in the early days
used to reboot before each use, and were diskless.  I don't think that
was ever really enough, either. The current workstations are mostly PC's
running linux, but I notice that they don't reboot before login anymore. 

Basically, what it comes down to is that one can't guarantee that such
machines can't be compromised if a single person is given (or obtains)
kernel loader privilege. The B1 certification requirement is for a
security compromise to /require/ the conspiracy of at least two
(presumably trusted) people.  

> Where SELinux comes into play is if you want to retain some of the 
> behaviors you get when you configure NFS to be cooperative with root 
> users on the client machines, but want finer grain control over what 
> those users can do. In this case you use SELinux to clamp down on what 
> the NFS server is capable of doing, and the clients can't bypass that 
> security as long as the server isn't breached.

Sure: What isn't served, can't be exploited.  But one usually doesn't
export /(root), and what is exported typically belongs to some user (or
users) for use by that user over the network.  One could limit some
subset of the exported files to only be accessible by a local process on
the server, but that probably isn't going to be the case most of the
time; usually ordinary users can't login to the server and have no
server-local processes.  Special users, like apache might work well with
selinux restrictions, but most users won't.

Selinux doesn't extend over a network. An Selinux process on a client
does not send its selinux tuple to the server. The server process has no
way to especially trust the client, selinux-wise. The selinux server
can't detect when some other person exploits on the client.  So Unix
permissions or Kerb creds govern the client/server interaction. Those
can be either spoofed easily (unix userid), or stolen (kerb cred &
passwd) if the client is exploited. So anytime you conclude the client
/can be exploited/, the server files are insecure against malicious
attack.

		--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000