Wednesday Feb 29, 2012

Solaris 11 has the security solution Linus wants for Desktop Linux

Recently Linus Torvalds was venting (his words!) about the frustrating requirement to keep giving his root password for common desktop tasks such as connecting to a wifi network or configuring printers.

Well I'm very pleased to say that the Solaris 11 desktop doesn't have this problem thanks to our RBAC system and how it is used including how it is tightly integrated into the desktop.

One of the new RBAC features in Solaris 11 is location context RBAC profiles, by default we grant the user on the system console (ie the one on the laptop or workstation locally at the physical keyboard/screen) the "Console User" profile.  Which on a default install has the necessary authorisations and execution profiles to do things like joining a wireless network, changing CPU power management, and using removal media.   The user created at initial install time also has the much more powerful "System Administrator" profile granted to them so they can do even more without being required to give a password for root (they also have access to the root role and the ability to use sudo).

Authorisations in Solaris RBAC (which dates back in main stream Solaris to Solaris 8 and even further 17+ years in Trusted Solaris) are checked by privileged programs and the whole point is so you don't have to reauthenticate.  SMF is a very heavy user of RBAC authorisations.  In the case of things like joining a wireless network it is privileged daemons that are checking the authorisations of the clients connecting to them (usually over a door)

In addition to that GNOME in Solaris 11 has been explicitly integrated with Solaris RBAC as well, any GNOME menu entry that needs to run with elevated privilege will be exectuted via Solaris RBAC mechanisms.  The panel works out the least intrusive way to get the program running for you.  For example if I select "Wireshark" from the GNOME panel menu it just starts - I don't get prompted for any root password - but it starts with the necessary privileges because GNOME on Solaris 11 knows that I have the "Network Management" RBAC profile which allows running /usr/sbin/wireshark with the net_rawaccess privilege.   If I didn't have "Network Management" directly but I had an RBAC role that had it then GNOME would use gksu to assume the role (which might be root) and in which case I would have been prompted for the role password.  If you are using roleauth=user that password is yours and if you are using pam_tty_tickets you won't keep getting prompted.

GNOME can even go further and not even present menu entries to users who don't have granted to them any RBAC profile that allows running those programs - this is useful in a large multi user system like a Sun Ray deployment.

If you want to do it the "old way" and use the CLI and/or give a root password for every "mundane" little thing, you can still do that too if you really want to.

So maybe Linus could try Solaris 11 desktop ;-)

Wednesday Nov 09, 2011

Password (PAM) caching for Solaris su - "a la sudo"

I talk to a lot of users about Solaris RBAC but many of them prefer to use sudo for various reasons.  One the common usability features that users like is the that they don't have to continually type their password.  This is because sudo uses a "ticket" system for caching the authentication for a defined period (by default 5 minutes).

To bring this usability feature to Solaris 11 I wrote a new PAM module (pam_tty_tickets) that provides a similar style of caching for Solaris roles. 

By default the tickets are stored in /system/volatile/tty_tickets (/var/run is a symlink to /system/volatile now). 

When using su(1M) the user you currently are is set in PAM_USER and PAM_AUSER is the user you are becoming (ie the username argument to su or root if one is not specified).  The PAM module implements the caching using tickets, the internal format of the tickets is the same as what sudo uses. The location can be changed to be compatible with sudo so the same ticket can be used for su and sudo.

To enable pam_tty_tickets for su put the following into /etc/pam.conf (the module is in the pkg:/system/library package so it is always installed but not configured for use by default):

su      auth required           pam_unix_cred.so.1
su      auth sufficient         pam_tty_tickets.so.1
su      auth requisite          pam_authtok_get.so.1
su      auth required           pam_unix_auth.so.1

So what does it now look like:

braveheart:pts/3$ su -
Password: 
root@braveheart:~# id -a
uid=0(root) gid=0(root) groups=0(root),1(other),2(bin),3(sys),4(adm),5(uucp),6(mail),7(tty),8(lp),9(nuucp),12(daemon)
darrenm@braveheart:~# exit
braveheart:pts/3$ su -
root@braveheart:~# 

If you want to enable it in the desktop for gksu then you need to add a similar set of changes to /etc/pam.conf with the service name as "embedded_su" with the same modules as is  listed above.  The default timeout matches the sudo default of 5 minutes, the timeout= module option allows specifying a different timeout.

[ NOTE: The man page for pam_tty_tickets was mistakenly placed in section 1 for Solaris 11, it should have been in section 5. ]

Update for Solaris 11.1, now that we have /etc/pam.d/ support it is recommended that instead of updating /etc/pam.conf the following lines be placed into /etc/pam.d/su

auth sufficient	pam_tty_tickets.so.1
auth definitive	pam_user_policy.so.1
auth requisite	pam_authtok_get.so.1
auth required	pam_unix_auth.so.1
auth required	pam_unix_cred.so.1


Thursday Aug 25, 2011

100% of Solaris users use RBAC

Some of us in the Solaris Security Engineering group been asked a few times recently questions like "so how many customers actually use Solaris RBAC ?"

The answer we give is usually variant of "For Solaris 10 onwards 100% of users use RBAC".

Surely that is wrong and we can't guarantee 100% of users of Solaris 10 and Solaris 11 are or will be using RBAC can we ?  We don't have data to back that up because we don't even know who all the users of Solaris actually are.

It actually is correct we don't need data on usage to back it up.  The reason being you can't turn RBAC off in Solaris 10 onwards it is always in use in parts of the system that 100% of users of Solaris always use.

The kernel always checks Solaris's fine grained privileges (82 distinct privileges in Solaris 11 Express), even if the process is running "as root".  So 100% of Solaris systems make RBAC privilege checks.

SMF always checks RBAC authoriations for any enable/disable operation and any change to or viewing of a property on a service - even if you are running 'svcadm/svccfg' as root.  Also SMF itself uses RBAC to set the privileges of services (sometimes defined in RBAC profiles sometimes defined directly in the method credential of the service definition).  Solaris doesn't run with out SMF so 100% of Solaris systems are using RBAC authorisation checks.

Several other parts of Solaris 10 also make authorisation checks, and in Solaris 11 there will be a increased number of those in some of the core administration utilities giving us the ability to have more fine grained control and enhanced separation of duty for some common administration tasks.   I'll post more on this when Solaris 11 is released.

In ZFS the operations performed by the zfs(1M) command first check if the user has an 'allow' delegation and then check privilege - again even if the user is root.

So 100% of Solaris users really do use RBAC - there is no means to turn it off - and this applies even if you use sudo rather than using a profile shell (eg /usr/bin/pfksh) or pfexec directly.

Wednesday Apr 18, 2007

RBAC vs sudo HOWTO Part 1 of N: Running (all) commands as root

This is part 1 of N (where N is yet to be defined but I intend for N > 1) where I'm going to describe some sudo functionality and explain how to do the equivalent thing with OpenSolaris RBAC.   There won't always be an exact match because the functionality of sudo and RBAC doesn't line up 1:1, each can be configured to do things the other can't.  In general I'm going to try and show how to do things rather than trying to justify why RBAC or sudo do things they way they do.  Where relevant I'll point out how they differ in solving a particular task.

Lets start with an easy case.  I want to give the user 'darrenm' the ability to run any command as root using sudo but don't require them to authenticate.   Lets first implement this with sudo: in /etc/sudoers we add this entry:

darrenm ALL= NOPASSWD: ALL

Lets try a simple example to show it works:

islay:pts/4$ id -a
uid=35661(darrenm) gid=10(staff) groups=10(staff)
islay:pts/4$ sudo id -a
uid=0(root) gid=0(root) groups=0(root),1(other),2(bin),3(sys),4(adm),5(uucp),6(mail),7(tty),8(lp),9(nuucp),12(daemon)

Great that appears to be working.

Now lets see how to do the same thing with OpenSolaris RBAC. There is a pre-defined RBAC profile that allows a user that is granted it the ability to run any command with the uid and gid of root.  We use usermod(1M) to give that to our user.


# usermod -P'Primary Administrator' darrenm

Now lets try our simple test again:


islay:pts/4$ id -a
uid=35661(darrenm) gid=10(staff) groups=10(staff)
islay:pts/4$ pfexec id -a
uid=0(root) gid=0(root) groups=10(staff)

You will see that there is a subtle difference in the output of 'id -a', I explicitly passed the -a argument so that I could point out the difference between sudo and RBAC here.  In this case is is mostly irrelevant but sudo has done an explicit initgroups(3C) call so all of the root users
supplementary groups are setup as well.  The RBAC pfexec(1) command didn't do that it just changed the attributes defined in the RBAC profile, in this case that is just the real uid and gid the process runs under.

Lets look at how this was actually defined in RBAC: 

$ grep 'Primary Administrator' /etc/security/exec_attr
Primary Administrator:suser:cmd:::\*:uid=0;gid=0

This says that for all commands (thats the '\*') set uid and gid to 0.  Lets also see how it was assigned to the user:

$ grep \^darrenm /etc/user_attr 
darrenm::::type=normal;profiles=Primary Administrator

We could have manually edited /etc/user_attr (or the nameservice equivalent) rather than,running usermod as we did above.
Now all you need to do is retrain your fingers to type 'pfexec' as the prefix to commands you want run as root rather than prefixing 'sudo'.

Thats all for now.

About

DarrenMoffat

Search

Categories
Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today