libhal-policy -> PolicyKit

[Ludwig Nussel]

On Wednesday 08 March 2006 06:33, Artem Kachitchkine wrote:
> Since you brought this up, I feel less shy about sharing how it's done in 
> Solaris. There are several mechanisms, which can be used separately or in 
> combination:
> 
> 1. Authorizations.
> 
> An authorization is a right assigned to users that is checked by privileged 
> programs to determine whether users can execute restricted functionality. It's a 
> simple ascii token, just like your policy. E.g. we have a CD recording auth:
> 
> $ grep cdrw /etc/security/auth_attr
> solaris.device.cdrw:::CD-R/RW Recording Authorizations::help=DevCDRW.html
> 
> The CD recording application, which still runs privileged, will only let you 
> burn media if you have the "solaris.device.cdrw" auth. By default, this 
> authorization is granted to all local users:
> 
> $ grep AUTHS_GRANTED /etc/security/policy.conf
> AUTHS_GRANTED=solaris.device.cdrw
> 
> Authorizations' smallest granularity is per user. E.g. when D-BUS authorizes a 
> client process, it retrieves the UID, and HAL can then use these to get the 
> authorizations associated with this UID.
> 
> I can run the auths command to see my authorizations:
> 
> $ auths
> solaris.device.cdrw,solaris.profmgr.read,solaris.jobs.users,solaris.mail.mailq,s
> olaris.admin.usermgr.read,solaris.admin.logsvc.read,solaris.admin.fsmgr.read,sol
> aris.admin.serialmgr.read,solaris.admin.diskmgr.read,solaris.admin.procmgr.user,
> solaris.compsys.read,solaris.admin.printer.read,solaris.admin.prodreg.read,solar
> is.admin.dcmgr.read,solaris.snmp.read,solaris.project.read,solaris.admin.patchmg
> r.read,solaris.network.hosts.read,solaris.admin.volmgr.read

That reminds me of resmgr's classes.

[some classes removed to shorten output]
$ sudo resmgr dump|grep lnussel
login lnussel :0
grant lnussel modem
grant lnussel desktop
grant lnussel sound
$ cat /etc/resmgr.conf{,.d/*}
class desktop
class sound
class modem
class desktop includes sound
allow modem user=lnussel
allow desktop tty=/dev/tty[1-9]* || tty=tty[1-9]* || tty=:*

When I logged in via kdm pam told the resmgr daemon that I am on :0 and granted
access to 'desktop', 'sound' and 'modem'. A different user on :0 would not get
access to 'modem'. Someone login in via e.g. ssh won't get any access at all
with the above config. Well, except for myself, I get access to
'modem' unconditionally.

Since resmgr is modeled around granting users access to device files classes
normally contain files.

$ sudo resmgr dump|grep seq\\\|tty
add /dev/ttyS0 modem file
add /dev/snd/seq sound file

A hal callout notifies resmgrd when devices come and go. fdi files specify the
class of a device.

resmgrd installs ACLs on the files I have access to.

$ getfacl /dev/ttyS0
getfacl: Removing leading '/' from absolute path names
# file: dev/ttyS0
# owner: root
# group: uucp
user::rw-
user:lnussel:rw-
group::rw-
mask::rw-
other::---

At the time resmgr was invented file system ACLs were not implemented so there
is also a library that can instruct resmgrd to open a file on the user's behalf
and send the file descriptor via unix domain socket.

$ resmgr open /dev/ttyS0
success
Received file on descriptor 4

So with resmgr we don't need cdrecord setuid root, it's able to just open the
device as normal user.

A class is just a string so if you want to have it the way you described how
Solaris works you could add a class 'solaris.device.cdrw' that doesn't contain
files. You can then ask resmgr whether the calling user has access to
'solaris.device.cdrw'. On SUSE Linux I'd consider this abuse though :-)

> 2. Privileges.
> [...]
> I hope it didn't come out too confusing. I think Linux has something similar to 
> privileges called capabilities - it might be a part of LSM (?), but as it 
> requires kernel support, it doesn't get sufficient attention AFAIK.

Capabilities work fine. Unfortunately there is no way to selectively
grant them AFAIK. The program must basically be started as root,
call prctl(PR_SET_KEEPCAPS), setuid() to some unprivileged user and
drop the unneeded capabilties. Ie ping still has to be setuid root,
there is no flag in the filesystem that says /bin/ping gets
CAP_NET_RAW.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   SUSE LINUX Products GmbH, Development
 V_/_  http://www.suse.de/