libhal-policy -> PolicyKit
Artem.Kachitchkin at Sun.COM
Tue Mar 7 21:33:21 PST 2006
> - They all permit X applications to run as root. This is just plain
> wrong on so many levels;
> - 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
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
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
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:
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
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
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
$ grep artem /etc/user_attr
- 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.
More information about the hal