3

Quick background: We have 40 workstations running Linux. NFS is used extensively for bulk data storage and home directories. This allows users to roam freely will relatively transparent file systems.

This is an educational environment where postdocs and students have successfully pulled off a coup of sorts. All have gained root on their individual workstations by grooming a technophobic PI who thinks IT people are evil. If I so much as suggest chroot or sudo restrictions, I'll find myself working out of a broom closet.

With that in mind, what's the best way to mitigate something like this below?

$ hostname
workstation1
$ whoami
john
$ sudo su jane
$ whoami
jane
$ cp -R /home/nfs/jane /mnt/thumbdrive/
user225874
  • 31
  • 2
  • NFSv4 is supposed to solve this problem using Kerberos (somehow). See maybe http://wiki.paraf.in/~parafin/linux/nfs4krb5 . I don't know the details so I'm just making a comment. – Mark Wagner Jun 12 '14 at 04:35
  • 1
    This isn't a good fit for Serverfault as the problem isn't valid in a [professional context](http://meta.serverfault.com/questions/4111/what-is-a-professional-capacity); you are unable to enforce your own security policy. You'll probably get some better feedback if we migrate this over to unix.SE. – Andrew B Jun 12 '14 at 04:44
  • it seems to me your already working out of the broomcloset if you are bypassed. Imho.. lay down the law.. and be a gentle god.. – Koen van der Rijt Jun 12 '14 at 07:21
  • @AndrewB University sysadmins get paid the same as every other sysadmin. – Michael Hampton Jun 12 '14 at 14:25
  • @Michael That has nothing to do with what I was saying at all. – Andrew B Jun 12 '14 at 14:49

3 Answers3

4

To clarify, is 'john' the technophobe? If so then change the su configuration and sudo configuration to always ask for the users password (even if you are root) before switching users.

If the users have thwarted the system and given themselves sudo, then theres a few problems here. NFSv3 and AUTH_SYS (the basic mechanism used for identifying users) is utterly broken when client machines are untrustworthy. You'll have to implement a stronger NFS authentication system such as GSS to avoid the problem.

Matthew Ife
  • 23,357
  • 3
  • 55
  • 72
  • 1
    Yep, kerberized NFS is the simplest solution here. (And you know you're in a real mess when Kerberos is the simplest solution!) – Michael Hampton Jun 12 '14 at 14:27
  • Thanks for this (and the chuckle). So I had heard of the kerberos option. I'm just not sure how it works. sudo su is a legitimate command and produces legitimate credentials in the traditional sense. Kerberos will reject this? – user225874 Jun 12 '14 at 15:20
  • @user225874 A local `su` changes your effective UID, but does not grant you a Kerberos ticket for the new UID (as you bypassed authentication). You need the credentials of the user you wish to impersonate in order to get a valid Kerberos ticket for that user, and the validity is verified by the NFS server. There's nothing the client can forge. – Andrew B Jun 12 '14 at 21:23
2

You have four choices, none of which are easy for the situation you're in.

Fix it at the server level

Ban every workstation under the purview of the person violating your security policy. What's the point of security otherwise?

Fix it at the client level

Take away root. Period. Anything short of this is a paper thin sleight of hand that will be worked around every time.

Burn it all

Implement a network filesystem with user based authentication. This is a complete redesign which will involve reconfiguring both the server and the workstations. (read: low traction)

Some people like to watch the world burn, others aren't given a choice

When faced with an employer that doesn't want to do the Right Thing, sometimes you have to let the fire burn itself out. If you're not allowed to perform your job function and curate the security of the networked filesystem, you may have to wait until a large enough security violation occurs that can be used to drive the point home.

This isn't the same thing as apathy. An apathetic sysadmin doesn't care. You do care, but occasionally it's necessary to let your employer feel the natural consequences of ignoring a problem. It's important to distinguish between the two, and this is a career skill. Pain is part of the healing process sometimes.

If you know someone who carries some weight whose files are located on an accessible NFS share to one of those servers, you may be able to make the point sooner with a private demonstration. The share in question doesn't have to be mounted by default, it will be enough that root access on one of those workstations is providing vector into files people have no business in meddling with.

Andrew B
  • 32,588
  • 12
  • 93
  • 131
  • I have to agree with this. Having worked in an academic setting, I understand users' desire to have control of their machines. However - *if* users have an expectation that their home directories are kept private, they need to accept some level of restrictions on their privileges. – EEAA Jun 12 '14 at 12:49
0

The problem is not being able to cp -R or rm -rf /, the thing which really scares me is the ability to impersonate users. You really need to tweak the sudoers or, if they can gain root access / know the password / how to change it, maybe you could do an ugly workaround and use CIFS instead of NFS and force them to provide their credentials just before mounting directories.

It breaks SSO, but providing legit credentials several times looks safer than being able to provide forged credentials after sudo su poorguy.

CijcoSistems
  • 116
  • 2