If the video is the 5 cent tour of Solaris RBAC then this is probably the book for the "self-guided walk through RBAC".

This is a transcript of an early draft version of the video (one which I canned as looking at 20 minutes of someone typing is just not that interesting...)

-Bart

The Self-Guided Walk Through Solaris RBAC

To make use of Solaris' Role Based Access Control you can use any "out of the box" version since Solaris 8, although to make use of fine-grained privileges you'd need either Trusted Solaris 8, Solaris 10, or more recent, such as Solaris Express.

The only preparation (optional, really) is to enable Solaris Auditing - which I recommend doing anyway, though it's important to note that for most systems logging only a limited set of events will do.

So: on a newly installed system the only account that can be used is the root account, so log in as root.

The first thing to do is to add (at least one) user account, so that someone other than root can log in and use the system. Here we create two accounts, one of which will be permitted to assume the root role:

# useradd -u 1001 -g staff -d /home/bart -s /bin/ksh -c "Bart who is also the admin" -m bart
# useradd -u 1002 -g staff -d /home/joe -s /bin/ksh -c "Joe who is just a user" -m joe

# passwd bart
# passwd joe

Now there are two user accounts on the system, as well as the root account. The problem with that root account is that anybody who has the password can walk up to this system and log in as root -- and, even with full auditing enabled, there'd only be a list of things done by root, with no way of knowing who actually ran those commands...

With RBAC there's an easy way to fix this: make root a role -- because fundamentally that's what roles are: from the system's point of view they're just regular accounts (with the expected entries in /etc/passwd and /etc/shadow), that cannot directly log in. The only difference between a role and a user account is one little item in /etc/user_attr: it says "type=role" for a role, and "type=normal" for a user - which is the default, so if there's no entry the account is considered a regular account.

The thing that differentiates roles from users in practice is a little PAM module pam_roles that checks wether an account is a role, and if so it denies direct log-in, and denies su by unauthorised users.

Making root into a role can be done with one command:

# usermod -K type=role root

though doing just this and then logging out would make it impossible to become root (though when booting the system in single-user the restriction that the account can't be used directly is not enforced. If nobody should ever be permitted to become root without an audit trail it's probably best to set an OBP or BIOS password, and have that be stored somewhere where the admins need to sign a log to retrieve it...), so (at least) one of the users should be permitted to assume the root role.

# usermod -R root bart

When now someone tries to log-in to the system as root the system won't let them, even if they have the right password -- they'll be shown an error message indicating that "Roles can only be assumed by authorized users".

If our other user (Joe) tries to su to root he'll get the same error message; only Bart would be permitted (with root's password) to become root. This is one of the obvious differences between sudo and RBAC: in sudo users generally authenticate using their own password, not the root account's password.

One of the big advantages of using roles is that an auditor can later determine who assumed which role, and - if auditing is configured to log this - what they did as that role.

This is pretty much the most basic use of roles that one can have, and in many circumstances be sufficient: only authorised users can become root, and there is a log of who did what on the system.

Now: you can also create other accounts as roles, but that in itself would not be very interesting: they'd be normal accounts, that can't do anything special -- so besides giving people controlled access to a set of files (those owned by the role) there'd be not much else those roles can be used for.

There may be some people that need to perform some tasks without being given complete root access, or they may have root access when needed but it would be convenient if some administrative commands could be used without the extra step of assuming a role.

In Solaris RBAC both of these are possible by assigning "rights profiles" (sometimes also called "rights", sometimes also called "profiles") to those accounts: assigning it to a user account gives that user the extra magic abilities that come with the profile, assigning a profile to a role provides those powers to users who are authorized to assume the role.

Most of the profile configuration files live in /etc/security, with the exception of /etc/user_attr - which we saw earlier.

A rights profile, described in prof_attr, is a container that can contain other rights profiles (so we can create hierarchies of profiles), plus possibly some authorizations, and maybe a list of commands and their attributes.

Let's start with those commands and their attributes: there is a list of commands in /etc/security/exec_attr and for each entry we can specify a number of things :

• the real and effective UID and GID - so when someone executes a command that's in a profile it'll run with those UIDS,
• and (as of Solaris 10) we can specify privileges.

(A brief refresher on privileges: Traditionally in Unix when a process tries to do something like accessing devices, configuring the system, or opening a file for which it doesn't have permission, the kernel would check the process' credentials and if the process was run with userid 0 (the root account) then the system call in question would succeed. With privileges the kernel now doesn't merely check the userid but instead checks a new process attribute, which is the privilege set.)

With RBAC we can now specify individual commands and the privileges they need, so we can let a user execute one or two commands with magical extra privileges, whilst all other commands run just the way they always have.

The exec_attr configuration file shows which profile an entry applies to, plus the command in question and the security attributes of the command (effective UID/GID, real UID/GID, and a list of privileges). If you don't specify privileges or UIDs/GIDs then those will be inherited from the parent process, just like any other command that a user executes.

In short a user can be allowed to run a couple commands with extra privileges -- perhaps, to change some of the graphics settings, to renew a DHCP lease, or to reset a print queue -- to help things run smoothly.

If there's a need to store files for a specific task, then assigning the rights profiles to a role is probably more appropriate, as the role's home directory can be used as a task-specific storage area.

A role would usually be given a function-specific list of commands to execute, for instance to support an operator, DBA, or auditor.

If it is mandated that a user enter a password before utilising magic powers then the only way of doing so is to assign the magic powers to a role, requiring the users to assume that role for the function specified.

If secondary authentication is not needed and if there's no need for shared storage (i.e. the role's home directory) then I recommend you just assign the rights profile to the user.

There is one constraint when assigning commands to users or roles:

in order to get those commands to run with different UIDs or GIDs or with extra privileges they will need to be executed from a "profile shell" -- /usr/bin/pfsh, /usr/bin/pfcsh, /usr/bin/pfksh -- or via the sudo-like pfexec command. These are the tools which know about rights profiles, and they ensure that the correct attributes are set when the command is executed.

A role gets a profile shell by default, but users who have special rights profiles will need to be given a different shell, or they must run the commands via pfexec (To reiterate for people familiar with sudo: pfexec is the closest equivalent on Solaris, but note that it doesn't do secondary authentication and doesn't currently limit command line options to any of the commands).

As an example we'll allow Bart to review the audit logs on the system, and will grant him the appropriate rights profile: (As root or other administrative account:)

# usermod -P "Audit Review"  bart

...and now Bart can run things like "/usr/sbin/praudit" (either by invoking the command via pfexec, or by running it from pfsh, pfcsh, or pfksh).

NB all users are given the "Basic Solaris User" rights profile by default as specified in /etc/security/policy.conf; it allows all users to run all commands they have access to -- but without any special attributes. Taking this away means that an account which uses a profile shell will be allowed to only run those commands listed in the output of profiles(1) and no others.

Besides specifying commands and their attributes in a rights profile we can also list authorizations. Authorizations are defined in /etc/security/auth_attr in a hierarchical manner. When a user is assigned a root or subroot of that hierarchy they get all authorizations which exist under it. Authorizations are attributes of users -- they're not "process attributes" like privileges, instead they are something that the kernel doesn't know about. They are used by individual applications to determine wether the application should perform some action on behalf of a user.

Even though privileges permit finer grained control over what applications are permitted to do, you can't use them to control modification of records within a file. Using application to mediate access to those records and authorizations in that application you can get the level of control that you desire.

One of the applications that makes extensive use of authorizations in this manner is the Solaris Management Console: it may permit one account (e.g. the system administrator) to create users, while not permitting that account to set the user's password or audit mask (which might be done by someone else, such as the security manager).

The Solaris Service Management Facility is one of the more recent users of authorizations which permits allowing a user or role to restart a service without permitting that user or role to reconfigure the service - and without the need to allow that user or role direct access to the process or its configuration files.

Authorizations are attributes of a user, so they can be assigned directly to a user (in which case they're listed in etc/user_attr), but they can also be assigned indirectly as part of a rights profile - in which case they're listed in /etc/security/prof_attr.

And, really, that's pretty much all there is to Solaris RBAC.

In summary, there are users and there are roles -- which are just like users, except that they tend to be used for specific tasks (system administration, operations and so on), and can only be "assumed" via su rather than accessed directly. Both types of accounts are defined in /etc/passwd & /etc/shadow, and their account type is specified in /etc/user_attr. In the latter file we grant users and roles authorizations, so that applications and tools which are authorization-aware (such as Solaris Management Console and the Service Management Facility) will perform their magic on behalf of authorized staff.

In user_attr we also assign "rights profiles" which may add extra authorizations and which will permit those users and roles to execute particular commands with extra magic privileges or different UIDs or GIDs, if they choose to do so via pfexec or a use of a profile login shell.

tags: introduction rbac solaris

Permalink | Comments [1]