BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
adtuck
Calcite | Level 5

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!!

1 ACCEPTED SOLUTION

Accepted Solutions
jakarman
Barite | Level 11

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

7 REPLIES 7
SASKiwi
PROC Star

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.

adtuck
Calcite | Level 5

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!

SASKiwi
PROC Star

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.

AndrewHowell
Moderator

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.

jakarman
Barite | Level 11

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 --<-----
adtuck
Calcite | Level 5

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.

Kurt_Bremser
Super User

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

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

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