SAS Metadata Security – Page 2

Testing Direct Access to SAS Metadata Bound Libraries and Tables

A little while ago, as part of the work on our recent Metacoda Plug-ins 3.0 R2 release, I used SAS® 9.3 M2 to set up a metadata bound library by following the useful instructions in the Setting Up a Metadata-Bound Library section of the SAS® 9.3 Guide to Metadata-Bound Libraries document. This post is about verifying that, post-setup, I no longer had direct access to the tables in the library.

Metadata bound libraries allow you to force clients to visit the SAS Metadata Server first, before they can gain access to the contents of the tables in the library. This gives the metadata server the opportunity to verify appropriate metadata access permissions. Direct access to those secured libraries and tables from Base SAS, without a visit to the metadata server, will be blocked. I first heard about metadata bound libraries at the SAS Global Forum in April this year and had been looking forward to trying them out. If you’re interested in them as well I recommend reading the documentation. Andy Ratcliffe wrote a NOTE: blog post about them recently too. If you don’t yet read Andy’s NOTE: blog I’d definitely recommend adding it to your RSS reader, and he also wrote a post last week about RSS in How Do You Read?.

This is the code I use to configure the metadata bound library (not the real pwencoded password):

libname hr '/opt/sas93m2/config/Lev3/SASApp/Data/HR';
proc authlib library=hr;
create
   securedfolder='/System/Secured Libraries/HR Secured Data'
   securedlibrary='HR Library'
   pw='{SAS002}ABCABCABCABCABCABCABCABC'
   ;
run;

After configuring the metadata bound library I wanted to verify that it had worked and that I hadn’t missed any steps. I wanted to check that the physical tables had been modified in such a way to prevent direct access from SAS processes that attempted to bypass the metadata server and go direct to the tables themselves. Continue reading “Testing Direct Access to SAS Metadata Bound Libraries and Tables”

Protecting the Unrestricted from Impersonation

I was asked a very insightful question about SAS® metadata security this week. This question and the ensuing investigation means I’ll now consider the inclusion of protections for unrestricted users in my metadata security plans. Especially for securing sensitive environments that have a separate group of user administrators who should not have access to login using unrestricted accounts.

Unrestricted users are very highly privileged users in SAS metadata. Metadata access controls do not apply to them. You might consider SAS metadata unrestricted users as somewhat like the UNIX root user.

The question I mentioned earlier came up when I was discussing how SAS metadata user administrators have the ability to impersonate other users for troubleshooting and testing purposes. This is a very useful feature. The person asked a question along the lines of:

Is it possible for a user administrator, someone in the “Metadata Server: User Administration” role, to impersonate an existing unrestricted user, and then as that impersonated unrestricted user make themselves unrestricted?

We decided to test it out and found that it was indeed possible.

This potential, for user administrators to elevate themselves to unrestricted via the impersonation of an existing unrestricted user, is easily protected against. An explicit denial of WriteMetadata to PUBLIC on each unrestricted user account will do the trick. This ensures that no user, other than an already unrestricted user, will be able to modify the account for those existing protected unrestricted users in order to attempt impersonation. e.g.

Unrestricted User Identity	Explicit Permissions (ACEs)
SAS Administrator	PUBLIC: -WM
Paul Homes (Admin)	PUBLIC: -WM

Of course these additional protections should go hand in hand with other measures to protect unrestricted users such as limiting knowledge of unrestricted user passwords (like the sasadm@saspw password) and ensuring that the adminUsers.txt file is only editable by appropriate administrators.

Update 12Dec2011: Someone has since alerted me to the fact that these additional protections for unrestricted user identities are actually documented in the SAS® 9.3 Intelligence Platform: Security Administration Guide appendices under Checklist for a More Secure Deployment where it states the following:

Consider reducing WriteMetadata access to the user definitions for any unrestricted users. This prevents restricted user administrators from updating an unrestricted user’s definition and then logging on as that unrestricted user. To add this protection, access the Authorization tab of each unrestricted user and add an explicit denial of the WriteMetadata permission for PUBLIC.

Baseline Security Metadata for a new SAS® 9.3 Deployment

When I’m reviewing SAS® metadata security implementations, I find it useful to have baseline security metadata to refer to. This baseline documents the initial state of metadata security (ACTs, ACEs, users, groups, roles, capabilities, protected objects, logins and internal logins) for a fresh new SAS software deployment. When reviewing a SAS installation I can then see what changes have been made since the initial software deployment.

The links below are for baseline metadata security reports I generated from a new SAS 9.3 deployment created from the EBIEDIEG single machine plan. The reports were generated using Metacoda Security Plug-ins V2.0.

New SAS 9.3 Lev3 EBIEDIEG Deployment (default exclusions): excludes protected objects and ACEs on protected objects under the following metadata folder tree paths:
- /ApplicationActions
- /Configuration
- /Portal Application Tree
- /Products
- /System
- /User Folders
New SAS 9.3 Lev3 EBIEDIEG Deployment (no exclusions): shows all security metadata including normally excluded objects

The first report has less detail as it excludes many things from areas of the metadata folder tree where SAS applications are known to automatically apply ACEs. This content is excluded to help me focus more on areas of the metadata folder tree where custom administrator-managed access controls are more likely to have been applied. The second report includes the excluded content for those times when I might also need to review those excluded areas for potential administrator-managed access controls.

WriteMemberMetadata Permission

The WriteMemberMetadata (WMM) permission was a welcome addition back when SAS 9.2 was released, because it allowed an administrator to distinguish between a users ability to manage a metadata folder from their ability to manage its contents.

In SAS 9.1.3 there was only the WriteMetadata (WM) permission and, if you had the ability to manage a folders contents, then you also had the ability to manage the folder too (and that could mean being able to change its permissions as well).

Starting with SAS 9.2, if someone had an effective grant of WMM then they could add and remove items from a folder, but to rename, move, delete, or modify the permissions on a folder then they would also need an effective grant of WM too. To allow someone to manage the contents of a folder, but not the folder itself, then we just needed to ensure that person had an effective grant of WMM and an effective denial of WM. As an aside, to avoid conflicts, the effective denial would ultimately be coming from a denial to PUBLIC, in combination with grants to appropriate groups, rather than a denial to the user themselves.

WMM Permission Patterns

In explaining some common patterns in the use of the ReadMetadata (RM), WriteMetadata (WM) and WriteMemberMetadata (WMM) permissions on SAS metadata folders, I find the following “truth” table useful:

Row	Effective Permissions			Comment
Row	RM	WM	WMM	Comment
1				-RM, -WM, -WMM: Folder not visible, can’t be modified, contents can’t be modified.
2				-RM, WM, WMM: Folder not visible, any WM and WMM grants are irrelevant.
3
4
5				+RM, -WM, -WMM: Folder and contents visible, folder cannot be modified, folder contents cannot be modified.
6				+RM, -WM, +WMM: Folder and contents visible, folder cannot be modified, folder contents can be modified.
7				+RM, +WM, -WMM: Folder and contents visible, folder can be modified, but folder contents cannot be modified!
8				+RM, +WM, +WMM: Folder and contents visible, folder can be modified, folder contents can also be modified.

When planning for effective permissions the green rows are the ones I aim for. They represent the common patterns, in increasing order of ability, as:

Row 1: Folder not visible to the user
Row 5: Folder and contents visible only
Row 6: Folder contents can be modified but not the folder itself
Row 8: Folder and contents can be modified

The grey rows (2,3,4) are variations on folder-not-visible: any WM and WMM grants are irrelevant because of the RM denial. I try to aim for the row 1 version. I find it looks neater and, when I don’t see any grant ticks, I don’t have to think at all about whether or not any permission is realistically available.

The pattern to avoid is row 7 with the red background. If someone ends up with those effective permissions they are in a confusing situation because they can manipulate the folder but not the folder contents.

WMM Permission Inheritance

The way in which WM and WMM inherit from their parents is a bit different to the other permissions. I find the diagrams below useful when explaining how the RM, WM and WMM permissions are inherited down an inheritance path.

In SAS 9.1.3 it was straightforward. Each permission on a folder, unless specifically set on that folder through an ACT or ACE, would inherit from the same permission on its parent folder:

With the introduction of WMM in SAS 9.2 this changed. Whilst the RM permission continued to inherit from RM in the parent folder, the WM and WMM permissions inherit from each other:

Unless specifically overridden, WM inherits from WMM on the parent folder (except on the root folder which doesn’t have WMM) and WMM inherits from WM on the same folder. You may have noticed WMM following WM when working in the SAS Management Console authorization tab. This might seem complex at first, but when you think about it, it becomes clear why this is necessary. A common pattern for allowing someone to manage a folder’s contents, but not the folder itself, is +RM,-WM,+WMM. With this inheritance model the inherited permissions on any sub-folders created by such a user would be +RM,+WM,+WMM and allow the user to manage any sub-folders they create. However, if the inheritance model was simple, with WM and WMM inheriting from the same parent permissions, that would mean the users permissions on any sub-folders they created would be the same as the parent (+RM,-WM,+WMM). They would be able to create sub-folders but then not have the ability to manage them (delete, rename, move etc) – very strange. This makes it clear to me why the WM/WMM inheritance model needs to be the way it is in SAS 9.2.

Authorization Manager Plug-in and Custom Metadata Permissions

Something I’ve only noticed recently, which I haven’t seen in the SAS® 9.2 What’s New documentation, is an apparent change relating to support for custom, or user-defined, metadata permissions in the SAS Management Console Authorization Manager plug-in.

I hadn’t noticed this change before because I’ve not yet had a need for custom metadata permissions myself. I don’t think they are used very much and personally I’ve only heard of a single site that has used them in a custom application.

A while back someone asked me about support for custom permissions in our Metacoda Security Plug-ins product. It was this request that originally alerted me to the custom permissions feature in SAS 9.1.3. Whilst planning a new release of our plug-ins, I had been thinking about ways to add support for them, but when I went looking for custom permissions in SAS 9.2 they appeared to have vanished.

Below is a screenshot fragment of the SAS Management Console 9.1 Authorization Manager plug-in. Notice the Permissions folder where, with a right click, you can create your own custom permissions.

Compare that with this next screenshot fragment for the Authorization Manager plug-in from SAS Management Console 9.2. Notice there is no longer a Permissions folder.

It looks like the ability to add custom permissions has been removed – at least via SAS Management Console anyway. Considering all of the many metadata security improvements in SAS 9.2 relating to applicable permissions, effective permissions and changes in inheritance paths, I think I can understand why. To provide support for custom permissions in the SAS Management Console Authorization tab in SAS 9.2 would require gathering much more information about how the custom permission should be handled than the simple name and description collected in SAS 9.1.3 would provide – you would have to consider what objects types it applies to and how the permission should be inherited from object to object.

So, for now, it looks like we won’t be needing to add support for custom permissions in our Metacoda Security Plug-ins product. However, if you have any information about the potential for custom metadata permissions in SAS 9.2 and/or would like to see them supported in our plug-ins then please let me know. I’d also be interested in hearing from anyone who might have used custom metadata permissions in SAS 9.1.3 and finding out about your experiences in migrating your custom applications that used them to SAS 9.2.

You can find more information about custom metadata permissions in the SAS Management Console 9.1.3 User’s Guide > Managing Authorizations > Managing Permissions