Roles and Policy

[David Zeuthen]

On Thu, 2009-08-13 at 15:41 -0400, Colin Walters wrote:
> Are these defined by upstream PolicyKit?  In other words, are these
> group names expected to be the same across OS vendors?  Or just the
> concept of the two groups, and their names can vary?

Not yet. We might want a polkit-policy tarballs that define these roles
(and possibly others) and the associated policy. I fwd'ed the original
mail to polkit-devel-list for other distros to consider this.

> >    but we probably want to allow installing trusted packages, install
> >    trusted updates and remove packages. Without asking for a password.
> >    Probably more - Richard?
> 
> Hmmm.  I very, VERY strongly think that installing OS updates should
> require no password by default in the unmanged case, and *especially*
> not a different "root" password.  System time is probably in that area
> as well.  If "make sound work without pops" requires the real-time
> process permission, then we definitely need that too.

Right, so granting the authorization to install OS updates w/o a
password for desktop_user_r and desktop_admin_r is what we want. 

> So it sounds like your desktop_admin_r is equivalent to the unmanaged
> case?  And desktop_user_r is roughly...what?  Computer lab?  But
> admins there aren't going to want people to be able to change the
> time.

The idea is that desktop_admin_r is for the owner(s) of the system - for
example, the owner of a single-user laptop. The idea is that
desktop_user_r is a non-owner or otherwise less privileged/trusted - for
example, your kids on the shared computer system at home.

That's the _idea_ anyway. We might want to change this if we want to.

> >  - This should put an end to the (IMO misguided) request "please add
> >   first user to the 'wheel' group". The new 'wheel' is
> >   'desktop_admin_r' and the new sudo(1) is pkexec(1).
> 
> See, this is what I don't like, is that "admin" here really means
> "execute arbitrary code as root" which I suggest we don't want to
> conflate with "install OS updates" and "make sound work without
> popping".

Right, so we just give this authorization only to desktop_admin_r. E.g.
allow standard users to install trusted OS updates. Ditto for the rtkit
stuff.

(And, btw, you _do need_ to enter the password for an admin user for
'pkexec bash' to work. Even if you are in desktop_admin_r. Ditto for
installing untrusted/unsigned packages. And this is fine I think.)

> >  - With support in the OS installer for automatically adding the first
> >   user to desktop_admin_r, we should be close to actually doing
> >   installs without the concept of a root password...
> 
> The most important thing is to remove the root password from the
> default UI flows,  But for example, the first time you typed "pkexec
> vi /etc/resolv.conf" (i.e. do something arbitrary as uid 0) when
> you're debugging some network problem, it'd be cool if that prompted
> you for a root password.  In fact, if one wasn't set yet, offered to
> let you set it.  Then we could axe the root password from the livecd
> installer prompt, and it becomes on-demand.

I think we want to completely disable the root account just like in OS X
and Ubuntu. In my view, it just doesn't make sense to have a root
password at all - shared secrets are really bad. One less password to
worry about is really what you want.

     David