Fencing in your SAS users with LOCKDOWN

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:

1. 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.
2. 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=-LOCKDOWN 

Actually, 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.