replace PolicyKit with resmgr

[David Zeuthen]

Hi,

Sorry for the lag; been traveling, busy with work stuff and a bit sick.
I also needed some time to reflect on your mail.

On Mon, 2006-06-26 at 15:01 +0200, Ludwig Nussel wrote:
> Hi,
> 
> I noticed polkit got a pam module that only serves the purpose of
> automatically granting the desktop-console privilege via polkitd.
> Isn't that exactly the same as with pam_console causing "at_console"
> to be set? The new pam module looks redundant to me.

pam_console does this and also some things that especially the Debian
people dislikes: changing device file ownership. Outside RH systems it
is not widely deployed so PolicyKit cannot really depend on it.

> If you need something that tracks logins via pam there is an
> existing, more flexible solution: resmgr[1]. The conditions for
> certain privileges are not hardcoded in the pam module but are
> configurable via a text file instead. Since we have no pam_console
> on SUSE Linux the desktop class is used by dbus for the "at_console"
> feature already. By default access to the desktop class is granted
> when you log in via X or on a text console:
> $ tail -1 /etc/resmgr.conf.d/99-desktop.conf 
> allow desktop          tty=/dev/tty[1-9]* || tty=tty[1-9]* || tty=:*
> 
> You can also match pam service, user name, remote host etc instead
> of tty.
> 
> Since resmgr classes are just strings they can be viewed as polkit
> privileges. To demonstrate that I wrote small replacements for
> libpolkit and libpolkit-grant that talk to resmgr instead of
> polkitd: http://www.suse.de/~lnussel/libpolkit-resmgr
> 
> This is how it looks:
> 
> $ polkit-list-privileges 
> privilege audioplayer (temporary)
> privilege pda (temporary)
> privilege scanner (temporary)
> privilege camera (temporary)
> privilege usb (temporary)
> privilege floppy (temporary)
> resource /dev/fd0 privilege floppy (temporary)
> privilege cdrom (temporary)
> resource /dev/hdc privilege cdrom (temporary)
> resource /dev/hdd privilege cdrom (temporary)
> privilege input (temporary)
> resource /dev/input/event0 privilege input (temporary)
> privilege video (temporary)
> privilege sound (temporary)
> resource /dev/snd/timer privilege sound (temporary)
> resource /dev/snd/seq privilege sound (temporary)
> resource /dev/snd/pcmC0D1p privilege sound (temporary)
> resource /dev/snd/pcmC0D1c privilege sound (temporary)
> resource /dev/snd/pcmC0D0p privilege sound (temporary)
> resource /dev/snd/pcmC0D0c privilege sound (temporary)
> resource /dev/snd/controlC0 privilege sound (temporary)
> resource /dev/mixer privilege sound (temporary)
> resource /dev/adsp privilege sound (temporary)
> resource /dev/dsp privilege sound (temporary)
> resource /dev/audio privilege sound (temporary)
> resource /dev/mixer1 privilege sound (temporary)
> privilege v4l (temporary)
> privilege dvb (temporary)
> privilege desktop (temporary)
> resource /dev/console privilege desktop (temporary)
> 
> 'temporary', 'restrictions' and any dbus connection related stuff is
> not handled by resmgr but I doubt those features are actually needed
> anyways. We don't need to 'protect' two processes with the same uid
> from each other and all privileges are revoked when the user logs
> out anyways. 

For the same reasons that people have a lock on their diary so the
adolescent younger sibling of yours in the same household don't mess
with it? Hmm.. ok, maybe that's a bad analogy.

In a nutshell it's like this: it's an extra layer of security such that
only the process who actually obtained the privilege can use it through
the D-BUS connection it obtained it through.

Of course some people say that once that an attacker can execute
unprivileged code in a session it's "game over". This extra layer of
security, however, basically comes for free.

> I don't understand what 'resources' are supposed to be
> so I just used them for the devices that are associated with
> classes.

Resources were meant to be a finer granularity of privileges so you
could be privileged only on e.g. certain resources, e.g. devices
specified by HAL Unique Device Identifiers (UDI's). For example you
would be privileged to be able to mount only "dave's usb key" but not
anything but that.

I think I'm going to remove the concept of resources from PolicyKit: it
turned out to be a lot more confusing for very little benefit (it's
trivial to spoof e.g. file system UUID's). It will also make the code
significantly simpler to read and audit when I've removed the resource
stuff in PolicyKit.

> Devices are what resmgr primarily manages. If you get access to a
> class, resmgr installs file system ACLs on the devices that are
> associated with the class. By using ACLs it's possible to have
> multiple concurrent logins of different users at the same time and
> each one gets access to the devices. resmgr falls back to chown if
> the fs doesn't support ACLs. So it behaves like pam_console (resp
> pam_devperm) then.

Oh, for the record, I'm more and more of the opinion that something like
gnome-volume-manager needs to set the ACL's through HAL when new devices
are added / removed. This would be nice; 

 1. in a completely locked down system g-v-m could be configured to
    prompt for auth a'la "please enter your password to use the digital
    camera" through PolicyKit

 2. UI applications that use non-standard devices / drivers / user space
    drivers (through e.g. libusb) could use exactly the same mechanism 

But this idea needs to be matured a bit, we need something to cleanup
the ACL's when the user logs out. Also need some way of specifying what
privilege is needed for the SetACL() to succeed. It's not terribly hard,
just needs some work.

It's all in line with the thinking that _all_ policy needs to come from
the desktop session, because only from the desktop session we can read
the logged in users setting (from gconf) and/or interact with the user.

(of course, all this applies to KDE as well, I just used GNOME
technologies as examples because that's what I know)

This, however, is a different discussion (if you must reply, please do
so in a separate mail with changed subject).

> Back to polkit. resmgr itself has no means for a user to acquire
> additional privileges like that pam-via-dbus interface of polkit.
> I don't think such a complex construct is needed though. Running
> "gnomesu resmgr grant $USER $PRIVILEGE" is equivalent and can be
> used by non-dbus applications as well.

I've read the gnomesu code and I'm not really happy with it. First, it's
setuid, second I'm not sure it handles PAM properly, third it's not
widely deployed. 

Finally, I envision most distros simply wants the user to input their
own password since the only reason they want auth is for trusted path
(e.g. to make sure that the request to e.g. format some harddrive
actually comes from a human user instead of a program).

> So what about using the already working resmgr as replacement for
> polkit (and pam_console)?

I'm just not sold on the idea; to mention a few concerns

 1. There needs to be a way for applications to install privilege
    descriptors, a'la what is on page 35 of [1]

 2. In the privilege descriptor it should be easy to specify what
    processes/users automatically receive what privileges. For example
    if I have a process running in a specific SELinux security context
    I really want it to have the privilege 'punch-hole-in-firewall'.
    See page 47 of [1] for the example.

    (oh, and this shouldn't sound SELinux centric; if the OS supports
     some kind of labeling that is enforced kernel side (e.g. you can
     get the label of the remote process over a socket) we can easily
     make D-BUS and PolicyKit support it)

 3. "gnomesu resmgr grant $USER $PRIVILEGE" just looks like a hack to
    me. It doesn't give the UI integration you really want, e.g.

                +----------------------------------------------------+
                | You need to authenticate to access the storage     |
                | device "Dave's USB Key".                           |
                |                                                    |
                |       User: [Dave___________]                      |
                |   Password: [_______________]                      |
                |                                                    |
                |   Would you also like to automatically allow       |
                |                                                    |
                | ( ) This user to mount a removable storage device  |
                | ( ) Any user to mount a removable storage device   |
                |                                                    |
                | [<- Drives and Media Preferences]          [Mount] |
                +----------------------------------------------------+

 4. It looks like resmgr is doing lots of stuff with device files and,
    ACL's, e.g. something that totally doesn't concern PolicyKit (with
    the removal of the concept of resources in PolicyKit it's going to
    do even less so).

These are probably my four biggests concerns.. in order. 

Let me try to turn the tables around: what are your concerns about
PolicyKit? To me it's kinda complementary to what resmgr is doing.

> For the future I am thinking about getting rid of the resmgr daemon
> by having the library store all state entirely in the fs instead of
> talking to a daemon. The library interface would still be
> compatible.

[1] : My GUADEC 2006 talk
http://people.freedesktop.org/~david/talks/system-integration-and-gnome-guadec2006-davidz.pdf

Sorry again for the lag.

Cheers,
David