Roles and Policy

[David Zeuthen]

On Thu, 2009-08-13 at 17:24 -0400, Colin Walters wrote:
> On Thu, Aug 13, 2009 at 4:20 PM, David Zeuthen<davidz at redhat.com> wrote:
> 
> > 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.
> 
> So my kids can't change the system time?  I dunno.  

System time is sorta security sensitive so I'd rather they didn't.

And Ideally we'd just use NTP - our NTP story is weak at best,
unfortunately.

> I think what we
> need here is a wiki page which takes the current set of PolicyKit
> actions (in the default desktop image only, i.e. not including say
> virt-manager), and puts those actions into one of your two suggested
> roles.

Dunno if we need a wiki page - maybe we can just keep it in the spec
file for now - otherwise it gets out of sync. 

Anyway, the point here is that it is _hard_ to figure out _how_ these
two roles should work - or what roles we actually need. I guess we need
to experiment a bit with this. I don't pretend to know.

> If we're talking about kids, I'd probably be more concerned about
> usage-time limits or browser filtering, but neither of those fall
> under PolicyKit.

Not directly, no.

> > (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.)
> 
> Right, OK.  No strong opinion here on what those things should
> require; we could make installing unsigned packages require you to do
> a little dance in front of the webcam for all I care =)

Again, this is security vs usability. The thinking here is that
operations that effectively give you a root shell requires trusted path.
E.g. 'pkexec bash', installing unsigned packages etc. fall into this
category.

So here you need to prove that you are the administrator - typically by
entering a password but.. I guess.. pam_rps or some PAM module with a
webcam and dance analyzing software works too. We also need this

http://www.youtube.com/watch?v=RfiQYRn7fBg ;-)

> > 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.
> 
> I don't disagree that a root password is dumb for the unmanaged case.
> But we do want to have a good story for people deploying computer
> labs, and at least this is where Ubuntu's original "use sudo for
> everything" kind of fails.  Also important here is the scenario where
> a technical person maintains a friend's or family member's computer.
> It should be easy for them to enable the root account and use it to
> recover/administer the machine.

The root account can be enabled by doing 'passwd root' from a root shell
obtained via 'pkexec bash' or booting into single user mode or booting
with init=/bin/bash or whatever.... Either way, maybe we shouldn't worry
about that until it's relevant... we still have lots of work to do.

FWIW, I still disagree that the root password is what we want - in your
usecase it is much better if the technical person just creates an user
account on the system and adds that user to desktop_admin_r - that way
he can login via ssh (using ssh keys) to that account instead of sending
the root password through a lot of intermediate systems (albeit in a
tunnel but MITM attacks aren't unheard of).

     David