Oracle Solaris 11.1 Security Lab

Table of Contents

Exercise S.1: Privileges
Exercise S.2: Using Rights Profiles
Exercise S.3: Qualifying Privileges
Exercise S.4: Safe Browsing
Exercise S.5: Locking Down Services
Exercise S.6: Privilege Debugging


This set of exercises is designed to briefly demonstrate some aspects of the privilege policy in Oracle Solaris:

  • Extended Policy
  • Rights Profiles
  • Integration with SMF (Service Management Facility)
  • Privileges are process attributes that are required by the kernel policy to perform specific services. Both the rights of the traditional superuser, as well as those of normal users, have been subdivided into about 80 privileges. By default, user processes are assigned a basic subset of privileges which makes the policy transparent. But the policy can be customized to empower or lockdown applications.

    The exercises are just introductions - you are referred to the Oracle Solaris Administration: Security Services for further information. In addition, the following man pages will be useful: privileges(5), ppriv(1), usermod(1M), profiles(1), svccfg(1M), and svcadm(1M).

    Passwords: User:lab Password:oracle1
    Role:root Password:oracle2012
    Some of the exercises require the root role.

    Exercise S.1: Privileges

    Task: Become familiar with process privileges.

    Lab: Use the ppriv command to view a summary of the effects of each privilege.

    lab@solaris:~$ ppriv -lv|less
            Allows a process to request critical events without limitation.
            Allows a process to request reliable delivery of all events on
            any event queue.
            Allows a process to set the service FMRI value of a process
            contract template.
            Allows a process to observe contract events generated by
            contracts created and owned by users other than the process's
            effective user ID.
            Allows a process to open contract event endpoints belonging to
            contracts created and owned by users other than the process's
            effective user ID.

    Lab: Use the ppriv command to view the privileges of your shell.

    lab@solaris:~$ ppriv $$ 
    2673:   bash
    flags = PRIV_PFEXEC
            E: basic,!proc_info
            I: basic,!proc_info
            P: basic,!proc_info
            L: all

    The letters E, I, P, and L, refer to the four process privilege sets.

  • The effective set E determines whether the process may perform an operation.
  • The inheritable set I specifies the privileges that are passed via exec(2).
  • The permitted set P specifies the privileges that a privilege-aware process can enable or disable during execution.
  • The limit set L is a mask that can be used to reduce the privileges passed via exec(2).
  • The flags field specifies how the policy is applied via exec(2). The PRIV_PFEXEC flag is set by any of the profile shells. Once it is set, it is inherited by child processes and RBAC execution is automatic. Two more flags, PRIV_DEBUG and PRIV_XPOLICY, are shown in Exercise S.6.

    Back to top

    Exercise S.2: Using Rights Profiles

    Task:Use the profiles command to create a profile and assign it to a user .

    Lab:In this exercise, you will use the profiles command to create a profile called Demo Extended Policy, which restricts the behavior of the visual editor, vi.

    Assume the root role and create a new profile interactively:

    lab@solaris:~$ su -
    root@solaris:~# profiles -p "Demo Extended Policy"
    profiles:Demo Extended Policy> set desc="Demonstrates extended policy"
    profiles:Demo Extended Policy> add cmd=/usr/bin/vim
    profiles:Demo Extended Policy:vim> set limitprivs=all,!proc_exec
    profiles:Demo Extended Policy:vim> end
    profiles:Demo Extended Policy> exit

    This profile removes the privilege proc_exec from the L set when vim (or vi) is executed. It can be assigned to the lab user via the profiles command or the User Manager GUI.

    Using the CLI:

    root@solaris:~# usermod -K profiles+="Demo Extended Policy" lab

    Using the GUI, from the Oracle Menu, select System->Administration->User Manager. When the User Manager GUI appears, click on the lock icon in the upper right, and select root@solaris. Then enter the root password, to assume the root role. Next double-click on lab, and select Advanced Settings.... Then click Rights Profiles, and double click Demo Extended Policy. Then click the Move Up button until it is first in the Granted Rights list. Finally, click OK twice.

    To demonstrate the effect of this profile, start vi as the user lab. Try something like :!date and notice that subshells are disabled. While vi is running, enter the following command in another Terminal, to view the current privilege sets.

    lab@solaris:~$ ppriv -S $(pgrep vi)
    2805:   vi foo
    flags = PRIV_PFEXEC
            E: basic,!proc_info
            I: basic,!proc_info
            P: basic,!proc_info
            L: all,!proc_exec

    Back to top

    Exercise S.3: Qualifying Privileges

    Task: Learn how some privileges can be qualified to apply to specific resources, such as filesystem objects, network ports, or processes.

    By default, privileges apply to all relevant objects. However, to prevent privilege escalation, all the zones's privileges are required to override the protection of root-owned objects. The scope of privileges can be qualified via rules, in which privilege sets are associated with specific objects. These rules are expressed by enclosing the qualified privilege sets between curly braces, followed by a colon and the associated object.

    Lab: Assign a privilege that only applies to a specifc file and command. The rule is added to the Demo Extended Policy rights profile.

    root@solaris:~# profiles -p "Demo Extended Policy" 
    profiles:Demo Extended Policy> add cmd=/usr/bin/cat
    profiles:Demo Extended Policy:cat> set privs={file_dac_read}:/etc/shadow
    profiles:Demo Extended Policy:cat> end
    profiles:Demo Extended Policy> exit

    Now as the user, try it out.

    lab@solaris:~$ cat /etc/shadow

    Note that the policy only overides the read permission bits for /etc/shadow by the cat command. Try accessing this file with another command like less or tail.

    Back to top

    Exercise S.4: Safe Browsing

    Task: This exercise demonstrates how an ordinary unprivileged user can use extended policy to restrict the behavior of an application like firefox.

    Lab: Start firefox in a sandbox which is only able to read and write files under $HOME/Downloads and $HOME/Desktop. It can be observed, for example, that the user's Documents directory is hidden from firefox.

    Since a normal unprivileged user cannot modify rights profiles, the profiles command is not used in this exercise. Instead, the -r option of the ppriv command is used to specify an extended policy rule set. Note that this exercise assumes that the the lab user has been previously set up as follows:

    root@solaris:~# usermod -d /export/home/lab -K defaultpriv=basic,\!proc_info lab

    Using the lab account, launch firefox using ppriv.

    lab@solaris:~$ ppriv -r "\
    " -e /usr/bin/firefox file:///$HOME/Desktop

    Like the proc_exec privilege used in Exercise S.2, the privileges file_read and file_write are basic privileges. When these two privileges are qualified, it is necessary to grant explicit access to every file that should be read or written. The use of the wildcard character, *, is essential in such policies.

    Exercise S.5: Locking Down Services

    Task: Use a profile to lock down the Apache web server so that it can only bind to port 80, and can only write to files owned by webservd.

    Lab: Create a profile called Apache2, which has a locked down extended policy. The apache22 service is then configured to use this rights profile. Note that in this exercise, nothing in the apache22 service ever runs as root.

    root@solaris:~# profiles -p "Apache2"
    profiles:Apache2> set desc="Apache Web Server Process Attributes"
    profiles:Apache2> add cmd=/lib/svc/method/http-apache22
    profiles:Apache2:http-apache22> add privs={net_privaddr}:80/tcp
    profiles:Apache2:http-apache22> add privs={zone}:/system/volatile/apache2
    profiles:Apache2:http-apache22> add privs={zone}:/var/apache2/2.2/logs/*
    profiles:Apache2:http-apache22> add privs={zone}:/var/user
    profiles:Apache2:http-apache22> add privs={file_write}:/var/user/webserv*
    profiles:Apache2:http-apache22> add privs={file_write}:/tmp/*
    profiles:Apache2:http-apache22> add privs={file_write}:/system/volatile/apache*
    profiles:Apache2:http-apache22> add privs={file_write}:/proc/*
    profiles:Apache2:http-apache22> add privs=basic,proc_priocntl
    profiles:Apache2:http-apache22> set uid=webservd
    profiles:Apache2:http-apache22> set gid=webservd
    profiles:Apache2:http-apache22> end
    profiles:Apache2> exit

    In this case the command is the start method for the apache22 SMF service. You can view and set its properties via the svccfg command

    root@solaris:/usr/lib#svccfg -s apache22
    svc:/network/http:Apache2> listprop start/exec
    start/exec	 astring	"/lib/svc/method/http-apache22 start"
    svc:/network/http:Apache2> setprop start/profile="Apache2"
    svc:/network/http:Apache2> setprop start/use_profile=true
    svc:/network/http:Apache2> refresh
    svc:/network/http:Apache2> exit

    Note that the Apache2 profile will be applied when the service is enabled.

    root@solaris:/usr/lib# svcadm enable apache22

    You can verify that the apache22 service is working by entering localhost in the firefox URL field.

    Back to top

    Exercise S.6: Privilege Debugging

    Task: Learn how to determine which privileges an application requires.

    Lab: Use the -D option of the ppriv command. It is easier to do the analysis if the Apache service is started interactively, using the apachectl script, instead of the SMF method script. Be sure to disable the apache22 service if it still running.

    root@solaris:~# svcadm disable apache22

    Now clone the Apache2 profile, by renaming it Apache-debug; select the existing cmd entry and rename it, too.

    root@solaris:~# profiles -p "Apache2"
    profiles:Apache2> set name=Apache-debug
    profiles:Apache-debug> sel<TAB><TAB>
    profiles:Apache-debug:http-apache22> set id=/usr/apache2/2.2/bin/apachectl
    profiles:Apache-debug:apachectl> end
    profiles:Apache-debug> exit

    Next, assign the cloned profile to the webservd account.

    root@solaris:~# usermod -K profiles+=Apache-debug webservd

    Now switch to the webservd identity:

    root@solaris:~# su - webservd
    webservd@solaris:~$ id                                                        
    uid=80(webservd) gid=80(webservd)
    webservd@solaris:~$ pfbash
    webservd@solaris:~$ ppriv -De /usr/apache2/2.2/bin apachectl start

    Verify that it is running correctly by examing the privileges of the first http daemon.

    root@solaris:/usr/lib# ppriv $(pgrep httpd|head -1)
    2958:   httpd
      5         Extended policies:
      6                 {net_privaddr}:80/tcp
      7                 {zone}:/system/volatile/apache2
      8                 {zone}:/var/apache2/2.2/logs/*
      9                 {zone}:/var/user
     10                 {file_write}:/var/user/webserv*
     11                 {file_write}:/tmp/*
     12                 {file_write}:/system/volatile/apache*
     13                 {file_write}:/proc/*
     14         E: basic,!file_write,!proc_info,proc_priocntl
     15         I: basic,!file_write,!proc_info,proc_priocntl
     16         P: basic,!file_write,!proc_info,proc_priocntl
     17         L: all

    Verify that the extended policies are correct.

    Back to top

    That concludes this lab session.