Solaris 11 Understanding Operating System Security with Rights and Privileges

Oracle Solaris 11 is a robust and complex Operating System that is often referred to a “carrier-grade”. In studying for the OCA Solaris 11 1ZO-821 you will not be expected to know the fully picture of how to administer security but it outlining processes involved is always a good starting point. We will look at file permissions on the /etc/shadow file that store users passwords and understand the mechanism that allows users to write to the file to change their own passwords.

Files can be regular files that we can read or write to such as /etc/shadow, they also can be executable such as /usr/bin/passwd which we can use to set and change passwords. Other file types exits including directories and symbolic links.

To list a files permissions or what is known as the mode of a file we can use ls(/usr/bin/ls) with the -l option.

ls -l /etc/shadow /usr/bin/passwd

The first column lists the permissions. We can see that the file /etc/shadow is read only by the user root; whereas the file /usr/bin/passwd is less obvious to read. It is readable and executable by the user, group and everyone else. Normally this would be denoted by r-x; however we see that is the user and group block this is replaced with a s. This indicates that as well as the execute permission the Set UID and Set GID permission is set. This means when the program runs it runs with the credentials of the owner and group owner of the file, root/sys rather than the current user credentials.

Another command that can be used to display permissions it the command stat(/usr/bin/stat). Use the formatting %A to see the permissions in human readable output and %a for the output to be in octal.

stat -c %A /usr/bin/passwd /etc/shadow
stat -c %a /usr/bin/passwd /etc/shadow

When the SUID bit or permission is set on a file when the file executes the permissions of the user owner are assumed. In this case, with the passwd program, users setting their password assume root permissions. This can be shown with the command pcred(/usr/bin/pcred). The command can be used to display the credentials under which a program is running. We can use this a standard users using the Process ID(PID) of the current program or BASH shell that we are in. The variable $$ holds the PID of the current process.

pcred $$

Here we see the:

• Effective UID (euid)
• Real UID (ruid)
• Set UID (suid)

The ID are all 100 the user ID of the account named user. Similarly we see this for the Group ID, this is set to the staff group 10 to which the user belongs. The bash shell has run normally and without the Set UID permission in place. Now observe what happens when we run the passwd program as the account user. In one terminal will start the passwd program running and leave it waiting at the prompt for the new password. remember the /usr/bin/passwd has both the SUID and SGID permissions set.

From another terminal as root we can search for the PID that the passwd program is running as:

pgrep -l passwd

From the output we can see that the PID of the passwd program is 1658, we can use this PID with pcred to display the permissions.

pcred 1658

The effective and set credentials for the user are now 0 whilst the real still shows as 100. The same with the group we see the sys group 3 as effective and set and the real being the staff group 10. The program is effectively running as the user root and group account sys.

The command can be shortened to one line of code if we use:

pcred $(pgrep passwd)

 

By now you can realize that the program can run as root but the original permissions of the shadow file, /etc/shadow, were set to just read even for root. In Oracle Solaris 11 we can go beyond permissions and into the realms of privileges. A privilege is a discrete right that is granted to a process to perform an operation that would otherwise be prohibited by the Oracle Solaris operating system such as, in this case writing to the /etc/shadow file. Most programs do not use privileges, because a program typically operates within the bounds of the system security policy. As administrators we can assign privileges but all privileges are assigned to the root role. So if we run as root as with the passwd program we gain all privileges for the execution of that program. To list privileges on a system we can use the command ppriv(/usr/bin/ppriv), using the -l option, if we send the output to grep we can search for file privileges

 

ppriv -l | grep file

From the output we can see there is a privilege to file_dac_write. If we have this privilege even though we are not listed as being able to write to the file in the ACL we will if we have this privilege. With only the file_write privilege we would have to be in the file’s ACL with the write permission to be able to write to the file.

We can any privileges we have assigned to us for a program using:

ppriv -v <PID>

Again we can use the variable $$ to see what privileges are current shell has.

ppriv -v $$

The key here in the output shown in the following screenshot is the letter E for Effective:

 

We have seen that the user has effective privileges set to basic when running the bash shell; we can list those privileges with the command:

ppriv -l basic

or

ppriv -lv basic

Adding the verbose option (-v) display information about the privilege. We can see that the basic privileges include file_write but this is only effective if the user has the write permission to the file, the same with file_read. To test this we can see what privileges are required to read from the /etc/shadow file:

ppriv -D -e cat /etc/shadow

The output confirms we need file_dac_read to read from a file where we do not have the permissions within the ACL of the file. In the same way we would need file_dac_write to write to file that we do not have write ion the ACL. This can be show by listing the description of the file_dac_write permission

ppriv -lv file_dac_write

if we run the passwd program as a standard user when the permissions include the SUID bit, the program runs as root. Root has all privileges so can write tot here file even though they are not listed in the /etc/shadow file’s ACL. If we run the passwd program again as we did before and check the privileges of the running passwd program. So we will run the passwd program as a standard user and leave it running.

 

From another terminal and running as root we can read the privileges of the passwd program

ppriv $(pgrep passwd)

We can now see that the Effective privileges are set to all, Inherited from the parent process we have basic as the shell that the user ran passwd from has basic privileges. All includes the file_dac_write so of course can now write to the /etc/shadow file.

Using a combination of file permissions set both on executables and regular files with privileges we can effectively maintain a secure structure on our Oracle Solaris 11 server or desktop.