On Thu, 2009-08-13 at 17:24 -0400, Colin Walters wrote: > On Thu, Aug 13, 2009 at 4:20 PM, David Zeuthen<davidz@xxxxxxxxxx> 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 -- Fedora-desktop-list mailing list Fedora-desktop-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-desktop-list
