Tag: SAS Configuration

SAS Restricted Options on UNIX

In a tweet by Gordon Cox last month, I was reminded of the restricted options facility available with SAS® software on UNIX platforms. This is capability where an administrator can set mandatory SAS system options at multiple levels of granularity: globally, per-group, and/or per-user. The reason for this post is that I don’t look at the documentation for this very often and every time I do it takes me a while to track it down. I always think its going to be in the UNIX companion in the Base SAS area… but it’s not! That gets me every time. Instead it’s tucked away in the Configuration Guide for SAS 9.2 Foundation for UNIX Environments (PDF) in Chapter 2 – Restricted Options. You can find this document in the Install Center section of support.sas.com under SAS Installation Note 36467: Documentation for a SAS® 9.2 installation on UNIX.

The context of the tweet was that the restricted options facility is another mechanism whereby a default setting of the NOXCMD option for SAS platform servers could be overridden for a subset of trusted users or groups in a SAS platform installation. The NOXCMD option is discussed in an earlier post: NOXCMD: NO eXternal CoMmanDs!

A quick summary of restricted options:

  • SAS Systems Options under UNIX set by an administrator, that cannot be changed by a user
  • Processed in the order global, group, then user. The last instance of an option is the one that wins.
  • Global restrictions are read from the file !SASROOT/misc/rstropts/rsasv9.cfg
  • Group restrictions are read from the file !SASROOT/misc/rstropts/groups/<groupname>_rsasv9.cfg
  • User restrictions are read from the file !SASROOT/misc/rstropts/users/<userid>_rsasv9.cfg

On Linux (at least) I can use the command “id -gn <userid>” to find out the effective group name for a user, given their user id. For example, “id -gn sassrv” might generate “sas“.

In my SAS 9.2 installation on Linux, whilst everyone else is still constrained by the NOXCMD option, I can ensure that the SAS Enterprise Guide user Bob Baxter, who has a user id of bob, can still use operating system commands in the SAS programs he runs on the SASApp server, by creating the file /usr/local/SAS/SASFoundation/9.2/misc/rstropts/users/bob_rsasv9.cfg with the following contents:

-xcmd

Of course, this only applies to SAS processes launched and run as the requesting user. Whilst it can be used to override NOXCMD for specific users/groups using a standard workspace server, it cant be used to distinguish between different users on the same stored process server, since all users will share SAS stored process server processes running under a shared identity (like sassrv). In that situation directing the users to separate SAS application servers would be more appropriate. There is an example of this in Jim Fenton & Robert Ladd’s SAS Global Forum 2010 paper 311-2010: A Practical Approach to Securing a SAS® 9.2 Intelligence Platform Deployment

Thanks to Gordon for reminding me about the restricted options facility.

NOXCMD: NO eXternal CoMmanDs!

SAS® platform administrators can get quite familiar with the SAS NOXCMD option, usually when someone asks why their programs that used to work (in a different SAS version or execution environment) are now failing. Perhaps the programs ran ok with SAS Enterprise Guide 4.1 using a SAS 9.1.3 server but now fail with SAS Enterprise Guide 4.2 using a SAS 9.2 server. Maybe they were developing some code using SAS Display Manager (I know it’s no longer de rigueur but us old-timers will still confess to using it from time to time – some even quite proudly as a badge of honour!). When that code gets deployed in a stored process on a SAS 9.2 server it then starts failing (hmmm perhaps we should have been developing and testing it in SAS Enterprise Guide or SAS Data Integration Studio after all ;)). You may have seen logs with this error:

1          filename lscmd pipe 'ls -al /tmp';
ERROR: Insufficient authorization to access PIPE.
ERROR: Error in the FILENAME statement.

… or maybe this one:

ERROR: Shell escape is not valid in this SAS session.
1          %sysexec mkdir /tmp/test;

… these are the common error messages seen when trying to run external operating systems in a NOXCMD constrained environment.

If you do a Google search for these messages you might find these resources:

  • Chris Hemedinger’s blog post “Using the X and SYSTASK commands from SAS Enterprise Guide” from Nov 2009, where he also explained how to overcome it with a single workstation installation of SAS Enterprise Guide and Foundation SAS.
  • SAS Problem Note 41058: Unable to submit X commands from SAS® Enterprise Guide® connecting to a SAS® Metadata Server when running SAS® 9.2 or later. I noticed at the end of this SAS note it says “… the commands will execute on the metadata server and not on your local PC“. Whilst this would be the case if it were the SASMeta – Workspace Server (a workspace server restricted to metadata administrators that runs on the metadata server machine), it would only be the case for the SASApp – Workspace Server if the workspace server happened to be on the same machine as the metadata server. In many of the installations I see, the metadata server runs on its own dedicated machine, and so this is often not the case. To clarify, it runs the commands on the host machine that the SASApp – Workspace Server is configured to run on.

In the rest of this post I am going to provide some more info, from the platform administrator’s perspective, and try to offer some suggestions and pointers to additional resources that help you with the goal of trying to work with the NOXCMD option. Ideally we want to try to retain the security benefits by not turning it off for the entire user base, in a shared platform environment, when a subset of your users encounter it and perhaps try to persuade you to turn XCMD back on!

The NOXCMD option disables a number of SAS language features that allow the execution of operating system commands such as:

The SAS documentation for NOXCMD can be found under its positive alternative, the XCMD system option. Here are links to the relevant documentation for Windows and UNIX.

We have become more familiar with NOXCMD in recent years because the the SASApp – Workspace Server, SASApp – Pooled Workspace Server and SASApp – Stored Process Server in SAS 9.2 installations commonly have the XCMD option disabled (i.e. NOXCMD). This is the default setting in newly installed SAS 9.2 deployments for its security benefits. To allow the general SAS user community (such as SAS Enterprise Guide users) to execute operating system commands on the servers, a SAS platform administrator has to make a conscious decision to enable XCMD, preferably after careful consideration of the potential security consequences ;). Here is a screenshot fragment showing where XCMD can be turned on in the server’s Launch Properties tab. You get to this tab using the SAS Management Console 9.2 Server Manager plug-in via the Advanced Options button on the Options tab in the server’s properties dialog.

While you are in the SAS Management Console, you might also notice that the SASMeta – Workspace Server is different in that it has XCMD enabled by default. Normal SAS users can’t use the SASMeta – Workspace Server because metadata access controls make it visible only to metadata administrators (members of the SAS Administrators group).

If you schedule SAS jobs to run in batch you might also want to check the NOXCMD status of the batch servers: SASApp – SAS DATA Step Batch Server, SASMeta – SAS DATA Step Batch Server and any others you may have. The XMCD/NOXCMD setting for these servers are specified not in metadata but in the batch server scripts. On Linux, my batch server scripts are in /usr/local/SAS/ebiedieg/Lev1/SASApp/BatchServer/sasbatch.sh and /usr/local/SAS/ebiedieg/Lev1/SASApp/BatchServer/sasbatch.sh. The SASApp one has -noxcmd whereas the SASMeta one has -xcmd. These are the default settings for batch server deployments in recent SAS 9.2 releases. If you have an older SAS 9.2 release (pre M2), you might find that the SASMeta one is also -noxcmd. The NOXCMD constrained SASMeta – SAS DATA Step Batch Server in older SAS 9.2 releases caused problems with scheduled metadata backups as described in SAS Problem Note 34923: A metadata backup that is scheduled to run by using the SAS DATA Step Batch Server might fail to copy the configuration files and the journal files

So what can you do if your security plan doesn’t allow you to enable XCMD for the general SAS user community, but some of your users, or batch processes, are failing to run operating system commands because of it? A couple of possible options include:

  • using/suggesting native SAS language alternatives to operating system commands where possible;
  • creating a new special purpose application server and associated workspace and/or stored process servers that are restricted in visibility (via metadata access controls) to a subset of trusted users/developers. There is a good example of this approach in Jim Fenton & Robert Ladd’s SAS Global Forum 2010 paper 311-2010: A Practical Approach to Securing a SAS® 9.2 Intelligence Platform Deployment

I’ll try to suggest some native SAS language alternatives to operating system commands in future blog posts. If you have any favourites yourself feel free to leave a comment.

I hope this post has helped you find out more about the NOXCMD option and that you don’t always have to turn it off at the first sign of trouble. Remember people tasked with managing security have a reputation to uphold: when it comes to security the first answer is almost always “no”, or perhaps the more pragmatic “no, but how about this alternative more secure method instead…” ;)