libhal-policy -> PolicyKit

[Artem Kachitchkine]

>  - They all permit X applications to run as root. This is just plain
>    wrong on so many levels;

Absolutely.

>  - Existing tools don't have wide adoption

And not integrated in to the OS.

>  - The 'su' problem should be solved upstream in a saner way than
>    what is available today

Yes.

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


2. Privileges.

A privilege is an attribute that provides fine-grained control over the actions 
of processes, as opposed to traditional unix all-or-nothing, super-user vs user, 
model. It's a per-process attribute, supported by the kernel. It's an addition 
to UID/GID, e.g. when D-BUS authorizes a client process, it can retrieve the 
privilege set associated with the connecting process along with uid/gid using 
getpeerucred().

There can be as many privileges as needed, right now Solaris has about 50. E.g. 
a privilege named "net_icmpaccess" is needed for a process to send/receive ICMP 
packets. For devices, privileges limit you *in addition* to device special file 
permissions, i.e. you can open a device RW, but have limited functionality 
available.

Now, since privileges are per-process, they are very flexible:

- You can assign a privilege to a user, then all user's processes will *inherit* 
it. On this machine I have privileges to mount filesystems and dtrace user 
processes:

$ grep artem /etc/user_attr
artem::::defaultpriv=basic,sys_mount,dtrace_proc

- Or you can "force" privileges on a per-command basic. This is done through a 
mechanism called profiles. A profile is a logical grouping of authorizations, 
privileges and commands.

- You can also force privileges onto daemons when they are started by SMF.


3. If that's enough, Solaris also has a notion called "roles". A role is a type 
of user account with associated authorizations and profiles. Roles cannot be 
logged in directly - users are said to *assume* roles using su(1M).


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.

-Artem.