SAS administrators now have another tool to keep SAS users from straying off their permitted path: the LOCKDOWN system option. The option was introduced in "stealth mode" for SAS 9.4. In SAS 9.4M1, it became a true, documented option. For the official guide to creating "locked-down servers", see the SAS 9.4 Intelligence Platform: Security Administration Guide
LOCKDOWN's primary purpose is to allow admins to close two perceived holes when supporting SAS programmers:
- It shuts down any SAS language feature that provides direct or indirect access to the operating system shell. This includes PROC GROOVY, and the DATA step Java Object and others. You also need to make sure that NOXCMD (shell command integration) and NORLANG (R language integration) are in place, since those avenues would circumvent any SAS-enforced system access.
- It allows file access to only those directories that a SAS admin adds to a "whitelist". This is the key benefit, since it prevents users from assigning arbitrary file-based libraries.
Enabling LOCKDOWN is a two-step process. First, you add the -LOCKDOWN option to the SAS command-line or config file. In a standard deployment, you can add it to the Workspace startup script. I tested this by adding it to my ../Config/Lev1/SASApp/WorkspaceServer/WorkspaceServer_usermods.bat file:
Set USERMODS_OPTIONS=-LOCKDOWNActually, I wanted to test two behaviors: LOCKDOWN versus NOLOCKDOWN. So I added logic to trigger LOCKDOWN only when any non-admin user was connecting to the SAS Workspace:
if %USERNAME%==sascrh( Set USERMODS_OPTIONS= ) else ( Set USERMODS_OPTIONS=-LOCKDOWN )My syntax is for a Windows BAT file. Similar logic applies on UNIX systems, but different syntax.
The second step is to use the LOCKDOWN statement somewhere in the SAS autoexec chain to list the operating system folders that you want the user to be able to access. Again, I need some logic to conditionally set this only when in LOCKDOWN mode. In my test, I modified WorkspaceServer/autoexec_usermods.sas to include:
%macro lockit; %if %sysfunc(getoption(LOCKDOWN)) = LOCKDOWN %then %do; /* this adds the user's home directory */ lockdown path="?FOLDERID_Profile"; lockdown list; %end; %else %PUT "System running under NOLOCKDOWN."; %mend; options source; %lockit; |
Note: I could avoid this script-level logic by simply creating another SAS Workspace context in SAS Management Console. I would then group certain users to use the locked-down one instead of the unlocked version. I would using SAS Metadata groups to control visibility/access into the appropriate servers.
If I didn't add the ?FOLDERID_Profile (Windows only, UNIX uses '~') to the list of allowed paths, my SAS Enterprise Guide users would receive a funny message when connecting to the SAS Workspace. As an inset, I also included the view of the SASApp tree; notice that it has no Files navigation:
That might be what you want. But if it's not, be sure to either allow the user to access the account's "home" directory, or else redirect the file navigation root to a usable location.
Tip for extra stealth: In my example, I used LOCKDOWN PATH= to specify the paths in my "whitelist". As an admin I can obscure that even further by using LOCKDOWN FILE=, and point to an external file (outside of the LOCKDOWN paths) that contains a list of the folders that I want to allow.
In my SAS Workspace log, I can check how the LOCKDOWN settings were reported when logging in as sasdemo, a non-admin user:
NOTE: These pathnames can be accessed when SAS is in the lockdown state: C:\Program Files\SASHome2\ReportFontsforClients\9.4 C:\Windows\Fonts C:\Program Files\SASHome2\SASFoundation\9.4 C:\SAS\Config\Lev1\SASApp C:\Users\sasdemo
All other paths are locked down after the "lockdown point" -- when SAS initialization is complete. Thus, if you know that your user needs access to a library or file reference that's not in your whitelist path, make sure that those resources are allocated during initialization, perhaps in pre-assigned libraries.
So what happens when the user tries to access a path that's not in the list of allowed paths? Here's an example of a FILENAME attempt and a LIBNAME attempt:
24 filename out "C:\Projects";
ERROR: The path C:\Projects is invalid because it is not in the
list of accessible paths when SAS is in the lockdown
state.
ERROR: Error in the FILENAME statement.
25
26 libname offlimit "u:\Dept\HR\Secret";
ERROR: The path u:\Dept\HR\Secret is invalid because it is not
in the list of accessible paths when SAS is in the
lockdown state.
ERROR: Error in the LIBNAME statement.
If you decide to use LOCKDOWN in your environment, I recommend that you allocate plenty of time to test -- for yourself and for your users. It's very easy to accidentally exclude a file path that you need to perform work. These might be items that you decide to then add to the whitelist, or else preallocate during the SAS Workspace initialization. Also, some SAS applications are not compatible with LOCKDOWN.
So, are you a SAS admin who admires Mordac, the Preventer of IT Services? It's okay to say Yes -- you're just doing your job. You can combine LOCKDOWN with Metadata-Bound libraries to really keep those SAS users in check.
19 Comments
Hi, Can you please suggest me ways to learn SAS coding from basics.
What would be the good way to start? Any links or any books to start with?
Thank you
Yes, you can begin with these free video tutorials on support.sas.com. For books, you might like Learn SAS by Example: A Programmer's Guide by Ron Cody.
Hi Chris,
This is very interesting.
- By any chance, could we restrict the LOCKDOWN system option for a single account / technical user group using System Option restrictions at the Foundation level ?
Thus we could expect the same behaviour as in your example.
Thanks for pointing out the supreme stealth mode, which uses a file out of the user's scope to define the White list : since LOCKDOWN mode prevents the user to assign any pointer Libname / Fileref to this location, it's successfully squaring the circle ! :-)
Ronan
Ronan, LOCKDOWN is an option that can be restricted, technically. So yes, if you configured an environment with user-specific RSASV9.CFG files you could trigger LOCKDOWN for certain users.
Then, if had user-specific AUTOEXEC files, I suppose you could point the LOCKDOWN statement to the appropriate whitelist per user. Or have a generic one as in my example, and include logic to trigger the LOCKDOWN statement conditionally.
Thanks, Chris. I couldn't retrieve the link but that's not important. I agree with your solution.
The permission loophole can be said to be closed, this time ;-).
Thanks Ronan - fixed the link in my reply.
Pingback: Making plans for SAS Global Forum 2014 - SAS Users Groups
Pingback: New superpowers for SAS administrators - SAS Users Groups
Hi Chris,
With this topic repeating there should be the repeating notes. You are not surprised.
For the “to be” administrators:
Security amdin guide: http://support.sas.com/documentation/cdl/en/bisecag/67045/HTML/default/viewer.htm
Watch all those notes on the needed OS layer controls, mostly associated with –cautions-.
Locked-down Servers
“You can limit the reach and activities of a SAS server by putting it in a locked-down state. This feature supplements the standard operating system-level and metadata-layer protections by giving SAS processes access to only specific physical resources on the server. This feature is intended for sites that need an extra level of security. For example, you might want to physically segregate sensitive data from other data by placing the sensitive data on a separate, locked-down server.”
Not only this bisecag is having those notes, a lot of other SAS manuals having same ones (RTFM).
- For SAS-VA (6.4 vaaug.pdf 105) mentioning that with the data-administrators.
- For metdatabound see: Who Should Use Metadata-Bound Libraries?
“You have not already met your security requirements through a combination of physical layer (operating system) separation and customized configuration of your SAS servers.”
http://support.sas.com/documentation/cdl/en/seclibag/66930/HTML/default/viewer.htm
It is a killing factor to analytics trying to put those in a fixed process like most business proceses. That is the old COBOL waterfall approach building silos in organizations.
The gains should come form the freedom of doing anytics on data. The big successfactor of Excel. The major differentator to Excel do that in a controlled auditable way.
The real world problems:
• Just focussing on some this technical features in SAS is giving a lot of people the false hope they do not need to understand OS-layers.
• A very old IT approach of not wanting or capable to cooperate wiht analytical environments. For Unix environments using those by users is often not in scope.
• There are many organizations lacking the required knowledge for OS-layers.
• Role Based Acces Control, being auditable traceable, data governance with standard of good practice
Just words don not help much, perhaps images will do.
It is a misperception on how to get a secure installation, something like:
http://www.geekfill.com/wp-content/uploads/2011/10/w6nh2.jpg
As the OS layers are the foundation of your installation, ask yourself what happens when that foundation is not reliable.
Information is not physical as that for most people too difficult. Build something nice on top and things like this happen:
http://www.gizmodo.in/science/How-The-Corvette-Museum-Rescued-Its-Cars-From-A-Giant-Sinkhole/articleshow/32441426.cms
By the way(1):
SAS has missed the opportunity to be kept present at log-analyses for security auditing. Once Mics MXG (SAS IT service visison) where wanted skills.
Those people (secyurity auditors) have developed big aversion to SAS on their big data analsyes, pulling in other tools for BI and analytics into companies.
By the way(2):
Encrypting SAS datasets is a nice feature of SAS-foundation. But using EGuide….. no available features to do that.
Even a system-failure when you try to add records to encrypted dataset with EGuide. It removes the read password without any note of that.
All very annoying and I see them as failures.
SAS 9.13 portable is not working on my computer Windows 7 64 bit.
The following error comes in message box:
ERROR: Cannot open "C:\Program Files\SAS\SAS 9.1\nls\en\SASV9.CFG" SAS option '-PATH' not set. Check configuration file, SAS environment options or command line options. SAS option '-RESOURCESLOC' not set. Check configuration file, SAS environment options or command line options. FATAL ERROR: WRCODE=80000803, MODULE='HIINIT': PATH OPTION UNAVAILABLE Traceback SASTBTraceBackCtx has been called with a string ("vacrash") instead of a CONTEXT pointer. Address Frame (DBGHELP API Version 4.0 rev 5) 5C8D200D 051EBF30 tkmk:tkBoot+0x20FE9 5C8D1E0F 051EBF3C tkmk:tkBoot+0x20DEB 5C8C826E 051EBF5C tkmk:tkBoot+0x1724A 04B2754F 051EBF7C sashost:Main+0xD08BF 04A5D974 051EBF9C sashost:Main+0x6CE4 04A51A33 051EBFF4 sashost:rtmdoit+0x1DF 04AED53D 051EC000 sashost:Main+0x968AD 04A7C353 051EC050 sashost:Main+0x256C3 04A7AB9C 051EC080 sashost:Main+0x23F0C 04A5119D 051EC18C 0001:0000019D sashost.dll 04A5749A 0520FEA8 sashost:Main+0x80A 04A65EC1 0520FED0 sashost:Main+0xF231 04A62A97 0520FEE4 sashost:Main+0xBE07 04A66C20 0520FEF8 sashost:Main+0xFF90 01CB49C7 022A4248 0001:000139C7 os_exe.exePlease Help
Sounds like you have something wrong with your SASV9.cfg file, or perhaps it's missing or empty. I suggest that you work with SAS Technical Support on this problem.
Hi, Chris,
I encountered the problem of lockdown restriction you talked in you post. Would you mind teach me how to disable it, so that I can work normally.
ERROR: The path /Users/PC/Desktop/NE/TEMP/F_F.XPT is invalid because it is not in the list of accessible paths when SAS is in the lockdown state.
ERROR: Error in the LIBNAME statement.
Thanks for any help!
Ping, you will have to ask your SAS admin to add this path into the list of allowed paths. It's not something that you can do yourself, unless you have the admin capabilities to modify the LOCKDOWN "whitelist" per the documentation.
Ok, thank you very much!
http://support.sas.com/kb/52/078.html
... For example, a user who has Write access to an operating system directory (for example, in order to create physical tables) can use host commands to delete and replace files within that directory. Such commands operate independently of any metadata binding.
Currently, there is no workaround or solution for this problem. ...
Follow development of OS guys, needing to go for SIEM. --This is waiting for the collision.---
Jaap,
Yes, the documentation for the metadata-bound libraries makes it clear, I think -- this does not replace OS-based permissions for "tampering" with the data sets in the library. However, an unauthorized user cannot read the contents of the data, achieving the main goal of the feature. And SAS logging can alert you when a file has been tampered with.
SIEM is an interesting approach, but it also replicates the function provided by database systems that many of our customers use. I think it remains-to-be-seen what the demand is for a file-system-based level of control/monitoring that approaches the SIEM qualifications.
Hi,
Is there any java api to check if the server is in lockdown mode or not?
and java api to get the accessible folder list (whitelist) ?
There isn't a direct Java API for this. You can use Java to connect to a SAS session using SAS Integration Technologies, and then submit SAS programs to check things such as PROC OPTIONS and the LOCKDOWN statement, but I'm not sure that's what you want. Can you explain your scenario a bit more and perhaps I can suggest something?
Very interesting approach and a great write-up on a feature that is covered very sparsely. I have used this and made the usermods.bat file dynamically check AD memberships instead, which makes it easier for me/us to manage. If a user is a member of one of the specified ADs, they are in nolockdown, otherwise they will be in lockdown.
So thanks for the inspiration!