[BBLISA] Secure, authenticated file serving to untrusted clients

[Sean OMeara]

Grsecurity is stack protection and selinux is nothing more than extra
metadata in filesystem inodes.
Aka, they only work from within the context of a running "machine" or
kernel and do nothing to solve this problem.

If you can establish a tcp connection to an NFS(v3) (and are in the
acl list), there is NOTHING an NFS server can do to prevent you from
accessing every file on the share. If you control every node on the
network, you can attempt to secure the clients so users cant get root,
but what about the scenario of a userspace NFS client pretending to be
root?

Your only option is to have a protocol in place where a user needs to
authenticate themselves to the share, be it a kerberos ticket or a
password (cifs, for example).

I hear that NFSv4 offers authentication via kerberos but I'm not sure
if it's at the host or user level.

CIFS suffers from it's own issues (reflection attacks for starters).


good luck!

-s

On Fri, Apr 17, 2009 at 8:35 PM, Michael Sprague <mfs at komerex.com> wrote:
> Dean Anderson wrote:
>>
>> There are options to NFS to not trust root, which prevents accidental
>> root problems, but provides no protection against malicious root
>> problems. NFSv4 and AFS are a little better--you have to steal kerberos
>> credentials, but this isn't real hard if you have root on the
>> workstation and the target of hostile activity also logs in and exposes
>> their KRB ticket and password to theft.  NFSv4 and AFS are pretty good
>> against untrusted root users where the target of malice probably won't
>> log into the untrusted computer.  Beyond that, all network computing
>> suffers the same weakness. If you can't trust root, you are sunk: you
>> can't obtain secure computing from an unsecure, untrusted computer.
>>
>> This also has implications for software.  If you can't trust the
>> distribution of critical software (e.g. the OS), then you are sunk.  I've
>> been watching the activity of a project that is untrustworthy and
>> how that project is interacting with OS distro's.  We used to worry
>> about hackers breaking into source code repositories. What happens when
>> hackers operate the source code repository?
>
> I could be way off base here, but couldn't you use something like grsecurity
> or selinux to prevent even root from doing anything bad to the network
> attached storage?  That's basically what we do where I work and we use
> grsecurity.
>
> thanks,
> mikeS
>
> --
> Michael F. Sprague
> mfs at komerex.com
>
> _______________________________________________
> bblisa mailing list
> bblisa at bblisa.org
> http://www.bblisa.org/mailman/listinfo/bblisa
>