PackageKit policy: background and plans

[Peter Jones]

On 11/24/2009 03:49 PM, James Antill wrote:
> On Tue, 2009-11-24 at 14:22 -0500, Peter Jones wrote:
>> That reason isn't /quite/ right.  One big problem is that if you train a
>> user to input the root password over and over, what he learns is to type
>> the root password into a dialog box.  The result is that when some
>> non-privileged application asks for the root password so it can do bad
>> things with it later, the user will type in the root password, and voila,
>> a local attack against a user is now a root exploit.
> 
>  Sure, that's _a_ problem ...

That's what I said, yes.

> assuming the user has been trained. But that's a _big_ assumption,

No, not that they /have been/ trained. That the policy in question has
the ability to train many users. I think this is ,in fact, a very /small/
assumption.

> esp. when we are only talking about installing _new_ packages (doesn't
> happen often, so the user isn't trained to accept it).

We were discussing the dialog box in general, and not necessarily only this
specific use of it.

>  But, of course, taking advantage of a user trained to input a password
> without thinking is not the only attack ... another area of attack would
> be when you have an assumed small privilege escalation, that has no
> authentication (hence this thread).

Yes, but it's often helpful to talk about specific improvements that can be
made, not merely all problems that may emerge on a system.

Or, to put that a different way, your thesis in this statement is that
everywhere there's privilege escalation without secondary authentication
is a risk. While that's certainly not incorrect, I don't think there's really
much utility in discussing potential attack vectors in /bin/ping in *this*
thread.

>> The way around this is role-based privileges, which is what polkit is
>> implementing
> 
>  In so far as "role-based privileges" is code for "can be configured to
> N number of actual checks, including the auth_as_root check we are
> comparing it against". Then sure, it has to be at least as secure as
> auth_as_root because it can be auth_as_root¹.

It's a fair point that the policy as defined for the role still needs to
be a good one, but I think some people on this thread are dwelling on the
mistake that was made, while at the same time placing blame incorrectly
on the mechanism. That doesn't help us. The mechanism does improve things
if used well by application developers and admins.

>  But suggesting that whatever polkit is configured to use is
> automatically better than auth_as_root is, at best, misleading.

I wasn't meaning to suggest that the system as a whole is necessarily
more secure if you use a mechanism which allows for policy and role based
decision making.  I am suggesting that it certainly appears to be a good
method to make a system which allows for /less/ privilege escalation on the
whole while at the same time making a system which is more usable where
individual authorized users don't /need/ more privileges.  That's
improvement. For it to also be more secure, it's true that the policies
that govern the mechanism also have to be crafted in such a way as to
enforce security. But that's true with what we had before, too.

-- 
        Peter