PackageKit policy: background and plans

Gregory Maxwell gmaxwell at gmail.com
Mon Nov 23 18:24:13 UTC 2009


On Mon, Nov 23, 2009 at 9:37 AM, Krzysztof Halasa <khc at pm.waw.pl> wrote:
> Kevin Kofler <kevin.kofler at chello.at> writes:
>>> I never tick those boxes.  I'd like to know how to get rid of them
>>> entirely.
>> Upgrade to F12 (with the latest PackageKit update), there's no such checkbox
>> in F12's PolicyKit.
> This is good.
>
> Also we should remember that user entering root password in user's
> session makes the user account practically equivalent to root (it can be
> seen as a protection against incidental damage, but not against a real
> attack). The only secure way has to use a fully trusted path from the
> person to the root process - e.g. logging as root (or root-equivalent)
> initially, with a physically secured console (some sysrq-k or
> ctrl-alt-del combo which cannot be remapped or blocked by non-root etc).
>
> E.g. using su or in most cases sudo etc. makes the non-root account
> equivalent to root. This can be, of course, deemed secure as long as we
> accept and understand this equivalency.

There are many kinds of security threat out there. For example, a few dishonest
people within the fedora project could conspire to backdoor the heck out of
Fedora with a reasonable chance of not getting caught.  Does this fact mean that
we should not bother with signing packages or other security measures?

Likewise, someone could load up some kind of X sniffer that intercepts the root
password when its typed in. Someone could also break into your house
and take apart
your computer. Yet in many environments these threats are insignificant compared
to a co-worker or family member casually twiddling around with the machine.

I haven't tried the the fast user switching in fedora... Hopefully it is
using some kernel mode secure path to prevent users from stealing each others
credentials, if it isn't then one should be established for it. Why not use the
same facility to switch to a system administration desktop, locked down a bit by
default (use SE linux to make various unsafe user tasks like firefox,
open office, etc unable to run in this admin context) to discourage
casual use.

Surely this would be preferable to reducing the security against
common casual threats.




More information about the fedora-devel-list mailing list