replace PolicyKit with resmgr

[Ludwig Nussel]

On Tuesday 11 July 2006 00:28, David Zeuthen wrote:
> On Mon, 2006-06-26 at 15:01 +0200, Ludwig Nussel wrote:
> [...]
> > '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 see the security benefit. The price is that it forces
policykit to use a dbus connected daemon.

Btw, what happens if dbus or polkitd need to be restarted e.g. due
to a security update while users are logged in?
 
> > 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.

Good. If you want to treat "dave's usb key" different you could just
as well introduce a different privilege for it, eg
hal-storage-mount-daves-usb-key instead of
hal-storage-removable-mount :-)

> > 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. 

gnomesu is just an example. Yes it is broken, just like most su
GUIs. Being setuid is not the reason why it's broken though. A
small setuid helper that talks to the unprivileged GUI can be
audited and the technique is well understood. Wrt PAM compliance
usermode is quite good. I also like the concept of usermode. Some
time ago I've prototyped something that could be used as central
replacement for usermode as well as the various broken su GUIs:
http://www.suse.de/~lnussel/pamwrapper/

> 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).

Maybe. pam modules have to decide that if someone != root requests
authentication as root though.

> > 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]

Sure.

>  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.

Hmm, that idea somehow causes me itching.

>  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.

[insert gnomesu disclaimer from above here] The GUI runs
unprivileged, you can use a custom one for a specific purpose.

>                 +----------------------------------------------------+
>                 | 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] |
>                 +----------------------------------------------------+

What would happen next if the user checks one of the radio buttons
and clicks 'mount'?

The radio buttons refer to different privileges than what the dialog
is authenticating. So if you want to allow 'Any user to mount a
removable storage device' PAM might want to ask different questions
as policy applies different rules. Like for example only accept root
authentication for the privileges referred to by the radio buttons
whereas mounting one specific device only requires user
authentication. I don't think you want to bother users with such a
dialog in practice.

>  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.

I am concerned because they are not complementary. privileges and
ressource classes are basically the same thing. Sure PolicyKit and
resmgr (resp pam_console equivalents) can coexist on one system but
you'll have two policy databases then. One for access to dbus
methods and another one for device files. So if you e.g start a
second X session as different user you might end up being able to
burn CDs but not be able to mount them or vice versa. So there
should be one system for managing classes resp privileges and
tracking user logins. Installing ACLs is just a plugin for that
service. In fact resmgr originally did not install ACLs but rather
required applications to do open() via resmgr which would pass the
fd via unix domain socket if the user is allowed to open the device.
Kind of like calling a HAL method like Mount().

Another concern is that PolicyKit is too complex for it's purpose
(features and implementation). Also dbus might be a cool thing but
if there is a way to get the job done without dbus or even a daemon
I'd prefer to use that. Artem apparently also considers using a
stripped down library without polkitd.

> > 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.

cu
Ludwig

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