Turning root into God again with OpenSolaris/Solaris 10 and RBAC

As you all know the root account is the all powerful "god" of your operating system. Such a highly privileged and powerful object should not be daunted for running the tasks of a mortal. Such an object should not be disturbed for any reason.

Some trivial utilities require special privileges to carry out their intended task. The inherent DAC problem was solved with some dirty tricks such as the special Unix access rights flags that allow users to run an executable with the permissions of the executable's owner or group.

The way it works is that when the program starts it is using the privileges of its owner id to run (such as root), executes the privileged task and then it will usually spawn children with lower privileges and the program continues or will drop the high privileges and continue execution.

One classic example is the ping command found in all operating systems and is available to all users by default. In UNIX/Linux you will notice that it is setuid "god" !!!!

Admins let them root alone

I will present how one can remove the "setuid" bit from ping and still allow an unprivileged mortal user to use this trivial but yet necessary application without disturbing the root object. The RBAC feature of the OpenSolaris/Solaris 10 OS resembles the "sudo" application found on most Unix/Linux like systems. Solaris RBAC provides more fine grained access control.

etz@opensolaris:~$ ls -la /usr/sbin/ping
-r-sr-xr-x 1 root bin 55680 2009-05-14 18:52 /usr/sbin/ping

etz@opensolaris:~$ /usr/sbin/ping 192.168.2.100
PING esx.etz (192.168.2.100): 56 data bytes
64 bytes from 192.168.2.100: icmp_seq=0 ttl=63 time=6.297 ms

As you can see I am not lying about ping being setuid! First I will remove the special bit from the ping utility.

root@opensolaris:/usr/sbin# chmod u-s /usr/bin/ping

etz@opensolaris:~$ ls -la /usr/sbin/ping
-r-xr-xr-x 1 root bin 55680 2009-05-14 18:52 /usr/sbin/ping

etz@opensolaris:~$ ping 192.168.2.100
ping: socket Permission denied

This will indicate that ping is using some special socket option which requires high privileges. As it turns out ping must send and listen for control packets on a network interface.

In OpenSolaris ping is PA (privilege aware) executable which requires rewriting the application. With the OpenSolaris command "ppriv" we can inspect a running process privilege sets and attributes.

etz@opensolaris:~$ ppriv -v `pgrep ping`
6817:   ping -n 192.168.1.100
flags = PRIV_AWARE
E: file_link_any,proc_exec,proc_fork,proc_info,proc_session
I: file_link_any,proc_exec,proc_fork,proc_info,proc_session
P: file_link_any,proc_exec,proc_fork,proc_info,proc_session
L: none

A few basic facts for OpenSolaris and RBAC


Privileges: Privileges are rights to do an operation in the kernel. OpenSolaris has defined 70 privileges. The names and their description can be found in "/etc/security/priv_names". Every process has four sets of privileges.

E: effective privileges set
I: inheritable privileges set
P: permitted privileges set
L: limit privileges set

Role: A named set of authorizations or Privileges that can be assumed


So the ping command is implementing a some high privileged operation in the kernel. In order to find out which specific set of rights we are missing we turn on privilege debugging and run the process again.

etz@opensolaris:~$ ppriv -e -D ping -s 192.168.0.1
ping[6873]: missing privilege "net_icmpaccess" (euid = 101, syscall = 230) needed at secpolicy_net_icmpaccess+0x24
ping: socket Permission denied

Ok, so we need the net_icmpaccess privilege to successfully run the ping command. There are several ways to assign a privilege to a user. One is to assign the privilege to the user' shell process.

etz@opensolaris:~$ ppriv -v $$
6707:   -bash
flags = 
E: file_link_any,proc_exec,proc_fork,proc_info,proc_session
I: file_link_any,proc_exec,proc_fork,proc_info,proc_session
P: file_link_any,proc_exec,proc_fork,proc_info,proc_session

The bash process is missing the net_icmpaccess privilege from its E, I, and P privilege set. To modify the privileges for a running process we use the "ppriv -s" command.

root@opensolaris:~# ppriv -s PEI+net_icmpaccess 6707

This adds the net_icmpaccess privilege to the PEI privilege sets for the shell process of the user (id 6707)

etz@opensolaris:~$ ppriv -v $$
6707:   -bash
flags = 
E: file_link_any,net_icmpaccess,proc_exec,proc_fork,proc_info,proc_session
I: file_link_any,net_icmpaccess,proc_exec,proc_fork,proc_info,proc_session
P: file_link_any,net_icmpaccess,proc_exec,proc_fork,proc_info,proc_session

etz@opensolaris:~$ ping 192.168.2.100
192.168.2.100 is alive

Adding privileges with Roles to users

In order to permanently assign the privilege to the user for controlling ICMP packets we can create a new role. We will create a role named "Network diagnostics" and we will add the "net_icmpaccess" privilege.

root@opensolaris:~# roleadd -m -d /export/home/netdiag netdiag
80 blocks
root@opensolaris:~# passwd netdiag
New Password: 
Re-enter new Password: 
passwd: password successfully changed for netdiag
root@opensolaris:~# 

root@opensolaris:~# grep netdiag /etc/passwd
netdiag:x:102:1::/export/home/netdiag:/bin/pfsh

As you can see a new role is a normal UNIX system account with a special shell "/bin/pfsh". Now we need to create a profile which we will then use to assign the new privileges.

root@opensolaris:~# echo "Network Diag:::Profile for network Diagnostics:help=netdiag.htm" >> /etc/security/prof_attr

Add the new privileges to the bash shell and assign a profile name

root@opensolaris:~# echo "Network Diag:solaris:cmd:::/usr/bin/bash:privs=net_icmpaccess" >>/etc/security/exec_attr

Now we must assign the role profile "Network diag" to the role "netdiag" and finally assign the role "netdiag" to the user.

root@opensolaris:~# rolemod -P "Network Diag" netdiag
root@opensolaris:~# usermod -R netdiag etz
UX: usermod: etz is currently logged in, some changes may not take effect until next login.

Remove the privilege set before from the user and try his new roles.

root@opensolaris:~# ppriv -s PEI-net_icmpaccess 6707

Log in as the normal user etz and test ping functionality.

etz@opensolaris:~$ ping 192.168.2.100
ping: socket Permission denied
etz@opensolaris:~$ ppriv -v $$
6707:   -bash
flags = 
E: file_link_any,proc_exec,proc_fork,proc_info,proc_session
I: file_link_any,proc_exec,proc_fork,proc_info,proc_session
P: file_link_any,proc_exec,proc_fork,proc_info,proc_session

etz@opensolaris:~$ roles
netdiag
etz@opensolaris:~$ su netdiag
Password: 


$ bash
etz@opensolaris:~$ ppriv -v $$
7119:   /usr/bin/bash
flags = 
E: file_link_any,net_icmpaccess,proc_exec,proc_fork,proc_info,proc_session
I: file_link_any,net_icmpaccess,proc_exec,proc_fork,proc_info,proc_session
P: file_link_any,net_icmpaccess,proc_exec,proc_fork,proc_info,proc_session

etz@opensolaris:~$ ping 192.168.2.100
192.168.2.100 is alive

Summary

Solaris RBAC is really a very powerful feature which can be used to implement fine grained access control permissions on the underlying system. Solaris comes with a large number of predefined profiles ready to use and a large number of applications are also rewritten to be PA.

RBAC for the masses!

In the past, advanced security features where only available to proprietary operating systems and applications. Namely some of the well known advanced operating system security features appear in the following (MAC/RBAC/Resources/compartmentalization etc..) :

• Trusted Solaris


• IBM RACF


• CA ACF2


• CA Top Secret


• HP-UX Virtual Vault

The open source evolution

With the inclusion of the LSM (Linux security module) framework into the open source GNU/Linux kernel the Linux operating system (beginning of 2002) became the idle platform for accommodating new advanced security features based on an open standard specification.

The US National Security Agency developed the SELinux software components and helped integrate them into the GNU/Linux OS by developing the SELinux LSM. The SELinux LSM added native RBAC functionality to the Linux OS.
SELinux has been integrated into version 2.6 series of the linux kernel.

In 2008 Sun Microsystems released the first version of an open source UNIX System V derivative. In the same year Sun announced the collaboration of Sun with the NSA in an effort to incorporate their security research into an OpenSolaris community project called Flexible Mandatory Access Control (FMAC).

Advanced OS security features become available to the public and are now included in all major Linux distributions and the OpenSolaris project.

Security threats drive the evolution of mainstream OS access control models

Advanced security models have started being developed back in the seventies. Only used in very highly sensitive environments (mission critical applications/classified information processing systems). They where not platform independent and where extremely cumbersome to manage. The security models which where developed addressed mainly three security objectives for the underlying systems and its data:

• Confidentiality


• Integrity


• Availability

The market adoption of the typical DAC model and the lack of least privilege principles in software development, by application and system developers was mainly for the shake of simplicity, manageability and cost. Software developed on these bases served the wide research and development in the exploitation of high privilege software components.

Any process must be assigned only the least system privileges required to carry out the process's intended functions. Any process which does not follow the principle of least privilege is a potential attack vector for a malicious user/process. If such a process has high privileges the security implications of the successful exploitation may lead to the full compromise of the computing base and all its software components.

In the last years there has been heavy research on "Trusted Computing". The concept behind building a trusted computing base is based on the following:

• The core initialization component of the platform has a very small image fingerprint which has been developed based on good security principles and formal methods have been used to evaluate this component and the underlying hardware and software base. Software development and evaluation based on formal methods is a very expensive process.



• Ability to measure the integrity of each software component during boot time and to mediate every call from user space to the underlying system calls. Such a system is essential to implement a MAC model.



• Such a system should also be capable of proving that the computing base fingerprint advertised is authentic and has not been tampered with.

When the operating system is initialized and all OS services are available a security enforcement module is responsible for mediating all access from any object to the system resources and control access of objects based on fine grained security policy.

Commercial support of MAC enabled operating systems

In the last ten years all well known OS systems have evolved and are now capable of supporting the MAC or RBAC concept. Some operating systems provide native support for RBAC and others implement user space tools for implementing a less feature rich RBAC/MAC ability.

One of the fundamental problems of fine grained security controls in operating systems is their management and configuration. Imagine having 1000 objects, 10 privileges and 100 resources and you wish to define which object has which privilege on which resource. Add to this that your computing base is comprised of 100 different software packages and your system supports many users and services.

Luckily such operating systems nowadays, come pre-configured with a default set policies, privileges assigned to groups and groups already assigned to roles. Management tools have also been developed to make the task privilege and identity management easier. Based on the service your system will serve you can further restrict the security policy of your OS.