2

Imagine this scenario in a LAN: one Linux NFS fileserver (srv) and three Linux clients (A, B, C). There are files / directories on srv with root ownership and no access rights granted to non-root users. Those are the files this question is concerned with. I'll call them "root-restricted files".

A is the local sysadmin. He or she will need to access root-restricted files on srv freely.

B is a local developer who has sudo rights on his or her machine. However, B should not be able to read or write (or traverse) root-restricted files/directories on server. In fact, B should also not be able to access files on srv not owned by groups B belongs to, even though B has sudo rights.

C is a local user with no sudo rights. C should have access to normal files on srv, but no permissions to local or server root-restricted files.

Given:

srv at 192.168.1.1
A at 192.168.1.2
B at 192.168.1.3
C at 192.168.1.4

Would this /etc/exports accomplish the goals?

/srv/nfs        192.168.1.2(rw,no_root_squash)
/srv/nfs        192.168.1.3(rw,root_squash)
/srv/nfs        192.168.1.4(rw,root_squash)

Which other NFS options are recommended? But most importantly, is root_squash capable of achieving this solution if we assume the IP address cannot be not spoofed?

Next, assuming a developer with sudo rights on their machine could spoof their IP address and look like 192.168.1.2, which has no_root_squah, what solution is needed? LDAP + Kerberos? Something else?

Can our goal be accomplished with NFS at all? Is something like SSHFS or Samba 4 a better solution?

(Editing suggestions welcome if "root-restricted files" is not the best term.)

Improve this question
5
  • Can you run NFSv4? That's the only version that provides user authentication and uid and gid mapping. Commented Feb 2, 2018 at 5:55
  • Yes, NFSv4 is no problem. We don't really need UID and GID mapping as we keep both UID and GID synchronized across all machines manually. Commented Feb 2, 2018 at 6:03
  • For a user with local sudo rights, what is to keep them from accessing the NFSv4 server as a different UID? Say, a developer uses the UID of the bookkeeper to look at financial documents. How does one stop that? Commented Feb 2, 2018 at 6:05
  • @MountainX For a user with local sudo rights, what is to keep them from accessing the NFSv4 server as a different UID? Say, a developer uses the UID of the bookkeeper to look at financial documents. How does one stop that? You pretty much can't stop that, which is why you have to be really careful who you give sudo rights to, and with exactly what sudo rights you give them. Commented Feb 2, 2018 at 12:14
  • @AndrewHenle - yes, that's the issue we're trying to understand. Maybe SSHFS is the best solution, but people keep telling me that SSHFS is not designed to be part of a multi-user fileserver solution. Is there anything that will address this better? Commented Feb 3, 2018 at 1:08

4 Answers 4

Reset to default
2

NFS simply uses the UID/GID provided by the client. Using squash_root option in exports for the share maps the root user to anonymous user (nobody/nogroup). This doesn't prevent a malicious/compromised client from providing some other UID/GID, which might allow access to other files.

If you want to secure your NFS server from spoofed users, you need to use Kerberos to authenticate your NFS users. NFS with Kerberos also provides optional data integrity and encryption. To get a quick overview of what is involved, there is a quick howto in Ubuntu wiki.

Improve this answer
2
  • We have been reading about Kerberos, but in that reading we are seeing a lot of this: wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA "configuring secure NFS is challenging, especially when it requires setting up and administering a Kerberos realm. FreeIPA addresses this..." Commented Feb 2, 2018 at 9:04
  • Once you have Kerberos set up, you can use it for authenticating to other services as well. It is a bit of work, but you could always try it out on VM setup. Commented Feb 2, 2018 at 9:27
1

NFS sets permissions by UID and GID so as long as you have the same on both the server and client, you'll be fine. root_squash will prevent B from reading or writing any files or directories that you don't want even worth sudo rights and C doesn't have sudo rights anyway.

If you are worried about IP spoofing then there are other tools and methods that can be used for that. You can find them with a little research and decide which is best.

Improve this answer
4
  • Thanks. I should have mentioned in the question that I we will match UID and GID across all machines. Can you give me a few clues regarding tools to stop IP spoofing on a LAN? Commented Feb 2, 2018 at 5:39
  • @MountainX As a golden rule, you never have users in your server/control networks. Commented Feb 2, 2018 at 8:06
  • @RuiFRibeiro "you never have users in your server/control networks" Can you explain further what that means? We are a very small team and everybody has to be everywhere, but we do need some controls and we're trying to figure out what/how. Commented Feb 2, 2018 at 9:03
  • @MountainX you have separate switched and firewalled netblocks for your vms, servers and the management ips of routers and switches. no pcs there at all. Commented Feb 2, 2018 at 9:48
1

The best way to protect shared documents with NFS is to not give everyone the same shared root. In this example, I would make an local directory structure similar to the following:

/srv/nfs admin-machine(rw,no_root_squash)
  /srv/nfs/developer dev-machine(rw,no_root_squash)
  /srv/nfs/shared 192.168.1.0/24(rw,root_squash)
  /srv/nfs/protected acct-machine(rw,root_squash)

The problem with trying to protect a folder against unauthorized access by an NFS client is that anyone with root access can create a user that just happens 😉 to have a UID matching the person who that want to impersonate. (Of course, a malicious user with root access could also turn off acct-machine and change their IP address so that it uses the same address!) Long story short, NFS was never really designed to be super-secure.

To combat IP-spoofing, you'll probably want to look into a more secure file-access system like SFTP/SCP so that the server actually does password verification, or NFSv4 in Kerberos mode.

Improve this answer
4
  • Thank you. We are using SFTP/SSHFS currently. But many people say we shouldn't be as it isn't designed for shared access to a fileserver. NFSv4 in Kerberos mode interests us, but we heard that setting up Kerberos is very challenging. Next up for consideration is FreeIPA based on this and other articles: happyassassin.net/2014/09/07/freeipa-for-amateurs-why But before implementing a FreeIPA+NFS stack we wanted to explore any and all potentially simpler options. Everything seems to point back to NFSv4 + Kerberos with FreeIPA. Commented Feb 2, 2018 at 9:01
  • Samba may be an option for you as well if you don't want to go the full LDAP/Kerberos route (setting up a standalone server would likely be sufficient.) Commented Feb 2, 2018 at 9:13
  • Yes, I agree that Samba4 is an option for us. But @colt pointed out this complication "Due to limitations present when provisioning the AD DC role, Samba recommends that you not use a Samba domain controller as a file server" Commented Feb 2, 2018 at 9:25
  • Going full domain mode is almost certainly overkill for your network unless you have huge numbers of users! I'd just use the standalone server mode and change passwords on the server when needed. If you're using a desktop environment like GNOME or KDE, it can handle the password storing on a per-user basis; otherwise, you can mount the share at login. Commented Feb 2, 2018 at 9:45
1

If your goal is to "keep users with local sudo rights from having sudo rights on NFS file server", you can't disable root squash.

At all.

This /etc/exports

/srv/nfs        192.168.1.2(rw,no_root_squash)
/srv/nfs        192.168.1.3(rw,root_squash)
/srv/nfs        192.168.1.4(rw,root_squash)

will allow anyone with root access on 192.168.1.2 to create SUID executables on /srv/nfs that can be used to access any non-root user on the NFS server itself, 192.168.1.3 and 192.168.1.4, along with root itself on your NFS server - which directly contradicts your stated goal. Do any users on 192.168.1.3 and 192.168.1.4 have sudo access? If so, anyone with sudo access on 192.168.1.2 can lever their access on that server and also gain root access to pretty much your entire network.

Disabling root squash on anything is dangerous to the the security of your entire network.

That doesn't even address the problems noted by @ErikF in his answer with IP address spoofing.

At least you're not sharing the filesystems with anon=0. Yes, I've seen that.

Improve this answer
1
  • Can I conclude from your answer that no amount of authentication / directory services (e.g., Kerberos, LDAP, etc.) will overcome the flaw you pointed out? Commented Feb 2, 2018 at 20:43

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.