[PATCH] set required mount privileges via fdi file

[David Zeuthen]

On Thu, 2006-07-27 at 15:50 +0200, Ludwig Nussel wrote:
> > The important thing really is to be able to map this sanely to some UI
> > that an admin can understand, e.g.
> > 
> >         +------------------------------------------------+
> >         | ( ) No user can mount fixed drives             |
> >         | ( ) Any user can mount fixed drives            |
> >         | (*) Restrict mounting of fixed drives to       |
> >         |      the following users and groups:           |
> >         |      +-------------------------------+         |
> >         |      | U davidz                     ^|         |
> >         |      | U dilbert                    ||         |
> >         |      | G admins                     ||         |
> >         |      | G releng                     V|         |
> >         |      +-------------------------------+         |
> >         |       [Delete] [Add Group] [Add User]          |
> >         |                                                |
> >         | ( ) No one can mount removable drives          |
> >         | ( ) Any user can mount removable drives        |
> >         | (*) Restrict mounting of removable drives to   |
> >         |      the following users and groups:           |
> >         |      +-------------------------------+         |
> >         |      | U jane                       ^|         |
> >         |      | U john                       ||         |
> >         |      | G admins                     ||         |
> >         |      | G secretaries                V|         |
> >         |      +-------------------------------+         |
> >         |       [Delete] [Add Group] [Add User]          |
> >         |                                                |
> >         |                                        [Close] |
> >         +------------------------------------------------+
> 
> I guess you need a third dimension in order to be able to also
> express the relationship to desktop-console here :-) Admins for
> example should probably be able to mount/burn a cdrom when logged in
> via ssh whereas jane only needs to when logged in on :0.

I'm pretty sure it's a bad idea to _even_ allow admins to log into a
desktop environment, how about that for an answer? :-)

Anyway, that said, one idea behind the current text based privilege
descriptor files (whether it's this 'root' character with uid 0 or
someone with a SELinux role or whatever) is that you can simply tweak
the desktop-console privilege descriptor to say

 Allow=uid:0

or if you're using e.g SELinux

 Allow=selinux_role:some_admin_role_r

or

 Allow=selinux_security_context:some_secure_context_t

or whatever once we get to implement SELinux support in PolicyKit. Or,
hey, the admin can use polkit-grant-privilege on the commandline to
grant himself the privileges he needs.

Anyway, this whole thing just comes down to

 1) the taxanomy we choose for describing privileges - e.g. have
    the concept of a 'desktop-console' privilege and maybe also
    'desktop-console-active' (for users on console and their session
    is visible e.g. fast-user-switching) and making functionality
    exported by HAL rely on these.

 2) how expressive we make the privilege descriptors.

Btw, all this is pretty much independent of the actual PolicyKit
architecture, e.g. 

 1) the concept of privileges

 2) trusted services asking a central authority if a given caller
    (e.g. :1.100) is privileged to do a specific action (e.g.
    hal-mount-storage-fixed) on a specific resource (e.g.
    hal:///org/fd.o/Hal/devices/volume_uuid_12345678).

    How this central authority (e.g. the org.freedesktop.PolicyKit
    service) determines this is just not very interesting from
    an architectural point of view.

 3) the process of obtaining privileges by authentication

and... if you should find a more expressive way to describe how to
determine if a given caller [1] is privileged or not please let me know
- seriously, I don't pretend to know that what's in the master repo now
is the best approach.

    David

[1] : note that I say 'caller' and not 'user'. We really need to look at
the caller not just the uid. Because the caller might run in specific
security contexts we care about, he might be connected to an X server
and so forth. So in that way, it's really MAC instead of DAC - we
possibly want to do a lot of checks all the time instead of relying on
just the uid.

And I believe that tracking the caller via e.g. the D-BUS connection
(guaranteed to be unique over the bus's lifetime) rather than the PID
(which is some UNIX specific thing that has no guarantee of being unique
over time) is the road ahead.