Enterprise File System Security

I'd have to say that very few (read 'two') organisations I've encountered implement good file system security. This is a pity because file system security is one of the most basic and easy things to get right. Many sysadmins, however, implement security for their systems on a user basis - which makes administration a function of the number of users you have.

Some time ago I established a reasonably bullet-proof filesystem security template that I have applied across NFS, CIFS/SMB and NCP file systems. The required exceptions are rare and (usually) easily managed. It does require management buy-in so you need to establish the business case very well (greater security, better administration etc). You will also need to lock-down the new user and modify user processes tightly which will require cooperation with HR. Coordination with departmental heads to ensure they have the ability to do their work unhindered by the file system security is essential.

General Notes

Never use masks or revoke permissions. The number of cases where this needs to be done is so rare it is almost non-existent. If permissions need to be revoked, simply apply zero permissions to the appropriate user or group. Trying to track down complex permissions with revocation is a nightmare - so don't do it.

With the exception of home directories, user specific directories, administrative accounts or services: Never, ever apply permissions to users. Create a group - even if that group has only one member - and apply rights/permissions to the group.

For Windows servers, apply all security via NTFS permissions and not via the shared permissions. You'll thank me for this one someday...

Also for Windows, be careful of the ACLs. There is no true inheritance in NTFS, so if you copy or move a directory structure, make sure you re-apply the permissions.

Get a handle on how the FS security works for your system. Know it backwards.

Home Directories

This is fairly simple. Only users have rights to their home directory with one possible exception (see submit). Make sure the users don't have the ability to add others to their directory or sub-directory. For Windows sysadmins, this means giving users 'Modify' instead of 'Full' permissions.

Departmental Directories

In general, you will want all members of the department to have R/O access to this tree. A group will need to be created for those that have write access. Beyond this, apply extra permissions at the lowest level only and create groups for those with extra access. Use a naming convention that allows you to know exactly by looking at the group what it is used for.

Shared Directory

These will generally a single tree with subdirectories for each department. Members of that department will have R/W access and others will have R/O access.

Temp Directory

This is to facilitate the temporary transfer of files. All users have R/W access and the directory has size restrictions on it. The entire structure is deleted every weekend after backup.

Software Directory

A R/O structure containing installable software and other R/O files. This structure is rarely backed up.

Submit Directory (Optional)

This requires some clever scripting. Essentially, there is a subdirectory for every user. Everyone has W/O access to these directories. They can copy files there, but not see or read the contents. Once copied, a script runs which moves the submitted files to the users Home Directory/submit and an email is sent notifying the user of the file, its location and who copied it there.

Additional FS Security

For anything not covered, create a group or groups with the necessary permissions. Make sure your naming conventions makes this fairly self-explanatory. Ensure that these group memberships are part of the user account creation process, which should NEVER have the statement 'Same as xxx' - this is simply bad administration.

Administration

Once you have settled upon the appropriate rights/permissions, tested them etc. Dump them to a text file and check them carefully. With the exception of home directories, write a script which will re-apply these permissions, deleting any others and have it run every night. When administering, modify the text file (or create a new one). By doing this, if someone with administrator access fools around and adds permissions (or removes them), all will be put back to rights overnight. As an extension, dump the rights/permissions before modification and compare them using diff with the original. Send an email alert out if there is a difference.

Followed properly, all you should need to do to alter a users permissions is to change their group membership. The number of times you will actually need to add more permissions will be small and now you can make them subject to a change request rather than a service request.

Enforcement

Executables should not exist in home directories or departmental directories. It is a simple matter to write a script to quarantine executable files (or make them non-executable) on a daily basis. If executables need to be shared, a change request should be submitted to the IT Department.

This is just a small but crucial part of best practice administration. It is simply better to have a total handle on your file system security.