PackageKit policy: background and plans

Matthew Garrett mjg at redhat.com
Sat Nov 21 23:38:21 UTC 2009


On Sat, Nov 21, 2009 at 01:19:12PM +1100, James Morris wrote:
> On Fri, 20 Nov 2009, Matthew Garrett wrote:
> > I don't think I'd agree with that. The common case for F10 and F11 will 
> > be for people to have installed a package once with the root password 
> > and then ticked the "Remember authentication" box. At that point, we 
> > have the same security exposure as we do with F12 (again, concentrating 
> > on the single-user machine case).
> 
> I never tick those boxes.  I'd like to know how to get rid of them 
> entirely.

If the user is asked to type in the root password in order to perform 
everyday administrative acts, then the current situation is that a 
user-level compromise is inevitably a root-level compromise a short 
period of time later. That's not a good tradeoff.

> > I definitely agree that there's a whole range of cases where this isn't 
> > the behaviour you want. But for the vast majority of our users, I don't 
> > think there's a real security issue here.
> 
> Are we moving toward a model where the user and the administrator are no 
> longer really separated?  Things seem to be regressing according to 
> whatever use-case some desktop developer thinks is important at the time.

I don't think that's the direction - if it were, we'd just have added a 
kernel patch that let us give a range of UIDs that had root privileges. 
I see the shift as being one that grants us a more fine-grained 
distinction between user and root, allowing certain acts that would 
previously have required a specific root login to no longer require 
that. Reducing the amount of time that someone's running as root (which, 
even in an selinux world, gives them significantly greater privileges) 
seems like a win *providing* that it can be done without those granular 
privilege escalation rights being used to perform things that are 
outside the security policy.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org




More information about the fedora-devel-list mailing list