Architecting, installing and maintaining your SAS environment

Privacy In a UNIX Server Environment

Accepted Solution Solved
Reply
New Contributor
Posts: 3
Accepted Solution

Privacy In a UNIX Server Environment

I am dealing with a privacy issue that I am unable to solve. Essentially, there is a .sas file saved on a UNIX Server. I am interested in changing permissions etc so that:

1. The .sas file can only be altered by the owner.

2. The contents of the .sas file can not be viewed (there is sensitive login information in the .sas file)

3. The .sas file can be run by a set of people chosen by the owner.

Things I have tried thus far:

1. Messing with chmod on the .sas file.

2. Saving the login information in an encrypted pwd.txt file.

My method "if all else fails":

Create a faceless login to replace the sensitive login information in the .sas file. This is admittedly less secure and therefore secondary, but certainly a possibility.

Any advice would be greatly appreciated!!


Accepted Solutions
Solution
‎06-30-2014 03:18 AM
Trusted Advisor
Posts: 3,212

Re: Privacy In a UNIX Server Environment

The first requirements are rather easy to implement with basic Unix security.

For the owner of those files do not use a personal key but a functional one.

Using the common sudo approach who can switch to that functional key is defined and monitored.

For the group access of files use a dedicated group by which you can control who is able to view those files.

The resistance from Unix and identity administrators is coming from old days Unix limits not allowing more than 8 (posix) or 16 (sun) groups per key. Windows is allowing 1024 as of n group max.  Modern Unix systems also are having higher limits.

The usage of pw encode is offering no really protection as the whole string is kept copy/paste for who can see that code.

Do you want to put privacy or changeable code in a save way you can use those os protections of Unix and use it not as readable sas code but put that in an encrypted sas dataset. The read password is no password protection but has the function of a salt.

This can be done with sas macros without any additional dependency like a metadata server.  You can find my example named as xkeypsw.

Would you need metadata definitions you are having the same kind of problems when promoting code to other environments. Having that kind of information removed from code you will get confirmed to common governance processes.

---->-- ja karman --<-----

View solution in original post


All Replies
Super User
Posts: 3,252

Re: Privacy In a UNIX Server Environment

What version of SAS are you running. Do you have a "SAS BI Server" setup with metadata server, compute server etc? How do you run your SAS program - from EG remotely, SAS display manager local/remote, batch?

Answers to these questions will help us to give you the right advice.

For starters you could use the PROC PWENCODE to encrypt your password. This doesn't stop anyone copying and pasting the encrypted version to run in their own SAS jobs, but you wouldn't be able to use it outside of SAS.

New Contributor
Posts: 3

Re: Privacy In a UNIX Server Environment

I am running SAS 9.3. And I am not sure about the server specifics. To run my .sas files I SSH to our server and use the command 'sas <filename>. I really appreciate the feedback though!

Super User
Posts: 3,252

Re: Privacy In a UNIX Server Environment

OK, so you are running your SAS jobs in batch mode. You could restrict the updating of the job and who can run it if you were to take advantage of SAS metadata security and turning your job into a SAS stored process. However if this is just for one SAS job and you don't know about configuring user credentials in SAS metadata or SAS stored processes then you could say the cure is worse than the disease!

Perhaps just encrypting the password and making your SAS job readonly with Unix permissions might suffice for now unless others can provide some smarter suggestions.

Moderator
Posts: 252

Re: Privacy In a UNIX Server Environment

Of your 3 requirements, #2 and #3 seem to be incompatible - how can the SAS code be run if it cannot be loaded?


One solution might be to compile the code and store it as a compiled SAS macro in a catalog. Retain the source SAS file (because you cannot re-engineer source code from compiled code), and restrict access to the source code to only the "owner". Allow users access to the catalog to run the code stored within the compiled macro.


Have a look at the SASMSTORE option for more information about how to store & execute compiled code.

Solution
‎06-30-2014 03:18 AM
Trusted Advisor
Posts: 3,212

Re: Privacy In a UNIX Server Environment

The first requirements are rather easy to implement with basic Unix security.

For the owner of those files do not use a personal key but a functional one.

Using the common sudo approach who can switch to that functional key is defined and monitored.

For the group access of files use a dedicated group by which you can control who is able to view those files.

The resistance from Unix and identity administrators is coming from old days Unix limits not allowing more than 8 (posix) or 16 (sun) groups per key. Windows is allowing 1024 as of n group max.  Modern Unix systems also are having higher limits.

The usage of pw encode is offering no really protection as the whole string is kept copy/paste for who can see that code.

Do you want to put privacy or changeable code in a save way you can use those os protections of Unix and use it not as readable sas code but put that in an encrypted sas dataset. The read password is no password protection but has the function of a salt.

This can be done with sas macros without any additional dependency like a metadata server.  You can find my example named as xkeypsw.

Would you need metadata definitions you are having the same kind of problems when promoting code to other environments. Having that kind of information removed from code you will get confirmed to common governance processes.

---->-- ja karman --<-----
New Contributor
Posts: 3

Re: Privacy In a UNIX Server Environment

This is more or less what I did to accomplish this:

Define a group of users.

Create a user specifically for the file, so that only that user has access. Then, give that user no password and an invalid login shell. So you have an account that cannot be su-ed into. Then, use sudo to allow people in a certain group to run commands as that user -- but only the commands you want to allow, only in the exact way you want to allow.

Essentially, users would then be able to run the .sas code without actually being able to read the file themselves.

Note: The main hurdle I faced was the pointlessness of SAS password encryption as noted by Jaap Karman. Although the password could not be understood, it could still be copy/pasted into other SAS login codes to run jobs as that user.

Super User
Posts: 7,780

Re: Privacy In a UNIX Server Environment

1. Do a chmod 600 on the .sas file

2. If the users that need to run the code can be assigned to a group, assign that to the .sas file and use chmod 640

3. If the password is used for SAS logins, use proc pwencode because the executing users will be able to read the code

Another method (more complicated, but hides the .sas file's contents from the executing users):

- use chmod 600 on the .sas file

- create a script that calls SAS and the SAS program

- assign that script to the user who maintains the program

- use chmod 700 on the script.

- specifiy (as superuser) in your sudoers file that a certain list of users can run the script as the maintainer user. sudo is a very powerful tool for things like that

---------------------------------------------------------------------------------------------
Maxims of Maximally Efficient SAS Programmers
🔒 This topic is solved and locked.

Need further help from the community? Please ask a new question.

Discussion stats
  • 7 replies
  • 963 views
  • 0 likes
  • 5 in conversation