01-29-2014 07:27 AM
You cannot make non-secure NFS share secure by just adding some ACLs.
If your requirements are simple, you can use traditional Unix file permissions to allow each user to access only the files that are appropriate to them. If your requirements are more complex, you might need ACLs, because they are a more flexible way to set file and directory permissions.
- if all your legitimate users must be allowed full access to all the files on your NFS share, you won't need ACLs and adding them does not make you any more secure at all.
- If you have one directory tree that must be accessible by one group of users, and another that must be accessible by another group, you can use ACLs, but using traditional Unix groups and file permissions will probably be simpler.
- if you have complex requirements, e.g. some files in a directory managed by group A must be writeable by group B too, you will very likely need ACLs.
But to make your NFS secure, you will first need to make sure of the following things:
- the share must not be accessible from unauthorized systems: this must be done with NFS export/share options in the NFS server, and/or by restricting the access to the NFS server by firewalls.
- the people accessing the NFS server must be authenticated.
Depending on the NFS protocol version used, there can be two ways to solve the authentication issue:
- with NFS v3 and older, the users' UID and GID numbers on the NFS client host must match their UID/GID numbers on the server host. The people with root access to the NFS v3 client host can switch to any user account, so they must be trusted. This is the traditional way, and this can be used with NFSv4 too.
- With NFS v4, you can optionally use Kerberos authentication: the users on the NFS client host will only be able to access the NFS share if they can authenticate with the Kerberos authentication server. The Kerberos ticket will then act as a proof of the user's identity for the NFSv4 server.
If the user identity information supplied by your NFS client host(s) cannot be trusted, there will be little point of setting any file/directory permissions or ACLs, as users will be able to work around them by switching to different user accounts.If you don't restrict which hosts can connect to the NFS share, someone might connect to it from their own Linux system, and pretend to be anyone.
Once the identity problem is solved, you must then find out who needs to access what, and then assign appropriate file/directory permissions and/or ACLs.
In HP-UX, the full support of ACLs over NFS requires NFSv4: with the older NFS versions, HP-UX may be unable to pass the ACL information over NFS. The ACLs will still be enforced, but the client will have no way of knowing what ACLs are set other than trying to do something and getting and "access denied" error message instead of the expected result.