Unix File Permission Recommendations and Best Practices

[CameronLawson]

Hi,

I've searched the web, global forum papers and this forum and can't find anything regarding recommended file permission settings for SAS Deployments on Unix.  Can anyone point me in the right direction with some links?  I'm basically looking for some reference material and real world examples.  The type of Information I am looking for is;

1.  Mandatory permissions for SAS to run by file / folder

2.  Recommended settings for WORK, SASUSER, GRIDWORK, user/group SAS libraries etc.

3.  Recommended settings for source code directories

4.  Any examples / recommendations in making x commands "safer" (limiting the available bash commands via custom .bashrc, any sas options etc.)

Thanks in advance.

Cam

[Kurt_Bremser]

It has been my experience that the default permissions SAS sets during the installation process are well thought out and do not need to be changed.

Regarding the "safety" of system commands: any out-of-the-box server install of a UNIX system is done with the experience of literally millions of system admins over decades as a background, so you can rely that ordinary users will not be able to trash more than their own data with a faulty command.

Consider which umask is best for your users, and set that as the default in the system scripts for defining new users.

WORK: The basic directory for the work location needs to be read/write/execute accessible to all users that will use the SAS system. Unless they share a common group, this directory will need to have rwx for others. Same goes for the UTILLOC.

SASUSER: Since this is located in a user's home directory by default, it is automatically subject to the same permissions that the home directory has; you may consider to alter the default permissions for user's home directories in the user creation script(s).

Regarding any other SAS libraries: This needs to be guided by the needs of your users:

- who shall see what?

- are shared libraries with write access needed? (for data exchange)

- does data need to be "hidden"?

Apply the same logic to directories where SAS codes are stored.

When setting up directories with shared write access, set up a quota system to avoid overflows. This includes the /home :smileyalert:, the WORK and the UTILLOC location.

Edit:typos

PS: UNIX admins need to take care of the proper state of their systems regarding hotfixes and security updates. This includes middleware like jboss and apache.

[CameronLawson]

Thanks Kurt,

I was hoping for some answers like you gave.  I figured that SAS would take care of the config area.

Thanks again.

[Kurt_Bremser]

One thing I did post-install:

Look for the locations of your log configs. Most often these are .xml files.

I edited those so that the server (metadata, STP, OLAP) logs are written to the /var file system, and the workspace server logs are witten in subdirectories of the user's home directories. Otherwise the SAS install user tends to clog up its home directory.

And I am not a fan of keeping UNIX users from accessing the OS commands through SAS. Especially when the same user can login to the SAS server with ssh.

[wahil]

I agree with KurtBremser. In our SASGrid environment we decided to deny the x commands for sas users. All the unix commands used before was changed for SAS Programs. In some cases, you could manager exceptions creating a cfg file for some users.

Besides this, our users haven't the "shell=true". This avoid the user from using ssh, sftp, and others tools.

For SASWork, all sas users have the same gid ("sas"), then we can put 770 as the default permission. Don't forget that cleanwork utility should have write access to this filesystem.

Regards.

[Kurt_Bremser]

Don't misread me: I favor giving users full access to the capabilities of the operating system. What's the use of having a Ferrari and not driving it?

It is my duty as the system administrator to provide for a safe and secure system environment.

Besides: a badly managed system can be mangled from within SAS without the use of the shell escape. Just overwrite a badly secured system file with a data step.

[jakarman]

Kurt, agree on your last answer. I noticed you are very motivated for that.

I have got very sensitive by bad experiences of people seek confirmations that with a SAS installation you put just in setup and that is all to get it running.

Getting the idea promoted all what you are doing to get it compliant has nothing special. Let that work easy to be outsourced, or let drop it all.

[acfarrer]

Since you mentioned GRIDWORK, I assume you are running SAS/Grid so you must have a shared file system which adds complications.

On Unix systems, ACLs (Access Control Lists) are a good option is regular Unix permissions are not enough. The POSIX version is most common but there are variations for each flavour of Unix so some experimentation would be needed. Lookup setfacl and getfacl .

For SASWORK, there is a WORKPERMS option somewhere in a .cfg file.

For x commands or any sub-shell execution, you should look at what users need to do. There is usually a SAS function alternative. Do you have specific use cases?

[jakarman]

Let us face it:  the security design by SAS is a failure when you need to be compliant according common regulations. I an referring to ISO27k COBIT/ITSM also mentioned with "standard of good practice". It  (the SAS environment) can and should be adjusted to those when you have sensitive data and being working in those kind of area-s.  I could get those chapters/paragraphs to it where it is failing (lot of work).  

Just mentioning the major ones. 

1.  Mandatory permissions for SAS to run by file / folder

     a/ A basic requirement is a segregation between the installation of program files  and the run-time execution. You installation should not be get compromised easily

     SAS institute is using one (who like root) for everything on the OS installation runtime-system-services run-time-user processes.

     b/ The installation (loadables) and configuration (user-data) are mixed up with SAS. They should be segregated as of DR Backup en Operationa; requirements.

     The advised file-system structure as proposed by Linux/Unix organizations is not followed.

     c/ With Unix there is a sasauth module this is failing to follow the common mandatory approach like the ssh implementation. The infamous inheritance of - spawner keys settings not of the ral executing effective user.

2.  Recommended settings for WORK, SASUSER, GRIDWORK, user/group SAS libraries etc.

     WORK, SASUSER, GRIDWORK These are set up to common requirements like using /tmp. This is giving the most easy problems as you cannot use /tmp but can refer to that. (needing more mountpoints/filesystems)

3.  Recommended settings for source code directories

    The proposed locations of code (source) log and data directories are part of the SAS configuration connected to an APPServer context.     

    With the user/group SAS libraries you are asking for data governance (data objects)  release management (ITSM DTAP) en maybe version management (developpers only).

    The SAS proposal is conflicting with an organizational hierarchy (often going along with RBAC) and another structure as being the defined by the business applications.

    These are two independent dimensions always being there.  

    You should go for your business requiements. Sorry that there is that big gap with a default SAS roll-out. 

4.  Any examples / recommendations in making x commands "safer" (limiting the available bash commands via custom .bashrc, any sas options etc.)

    Using the x command is as safe as your OS security implementation plan. That one, the OS security design following business requiements, should cover all business requirements.

    As your business has other goals than SAS institute with this part SAS institute should follow  your business requirements that is very different as SAS sales ideas are dictating your implementation.

Be happy when you are seeking confirmation that there is nothing to worry about or get worried for the alignment to your business. That is your choice.  

[ShelleySessoms]

Hi Cameron, it looks like Kurt gave you a good answer. So, I'm going to mark this question as "assumed answered." I believe it's always helpful, for you and others, to mark a question as answered. You can do this at any time, once you receive a helpful answer. Thanks for using the community!