On Thu, 2009-08-13 at 17:24 -0400, Colin Walters wrote:
On Thu, Aug 13, 2009 at 4:20 PM, David
Zeuthen<davidz(a)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