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.
Hi Paul,
Excellent post, as usual. Well done, Sir !
I was thinking, it might be useful to have a specific ACT for protecting the Persons or Groups objects when they’re created (like the Portal ACT for Permissions Trees folders). Baseline, only sasadm (+sastrust) are protected through an explicit ACE, and your test proves this is not enough to ensure a thorough security.
Cheers
Ronan
Thanks Ronan,
A specific ACT sounds like a possibility. I once took the SAS supplied %MDUGRPAC macro (that applies an “ACT Securing Groups” ACT to all unsecured groups in SAS 9.1.3) and created a variation, %MDUACTAC, that was scheduled to automatically secure all new unsecured ACTs with an “ACT Securing ACTs” ACT. A similar approach could be used to schedule a job that automatically secures unrestricted user accounts with the ACT you suggest. The number and turnover of such accounts would normally be very small. You wouldn’t be doing it to save any time just to ensure a consistent security policy.
Cheers
Paul