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


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