PackageKit policy: background and plans

[Gregory Maxwell]

On Mon, Nov 23, 2009 at 2:13 PM, Peter Jones <pjones at redhat.com> wrote:
> On 11/23/2009 01:24 PM, Gregory Maxwell wrote:
>> 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.
>
> Wait, you're arguing for this *instead* of finer-grained elevations of privilege
> governed by policy files which can be locally overridden safely?

I'm arguing for a secure way for users to obtain authoization to
perform administrative
operations instead of elevating them by default, and expecting the
computer operator
to go and hunt down the moving target of security holes in every new
version of Fedora.

This isn't mutually exclusive with finer-grained elevations but would
allow finer grained
elevations to stay out of the default install:  When additional
privileged is needed, the
system prompts you to authenticate via a secure prompt. At that point
if you have the
required credentials you could authorize the activity and, optionally,
permit that account
to perform the same operation in the future.

Obviously this kind of one-off permission granting isn't reasonable in
a large environment,
but large environments are the place where "customize the policy" is a
workable answer
especially when the systems is secure by default and customization can
be applied
selectively at the greatest pain points.

This is a point I think people miss when advancing the position that
it's only to be less
secure for convince sake as you can customize your way out of a
security hole: Customization
has a non-trivial cost. If it didn't we'd all run build our systems
from scratch rather
than using distributions.  To customize you must learn, understand,
and track changes from
version to version. If you're only customizing to make your systems
easier the customization
trade-off is easy to balance: When something annoys you, you learn
about and then customize
only that.  But when you need to customize to get the expected
security behaviour you must
carefully evaluate all the security properties because insecurity is
largely invisible
until its too late.


>> Surely this would be preferable to reducing the security against
>> common casual threats.
>
> I think you've characterized things backwards here.

Perhaps. I know that in my environment someone running software on my account to
sniff the credentials is less likely than someone sitting at my
computer and twiddling
knobs while I walk away (but not long enough to get away with
rebooting the system).
If they could sit at my account they could start up such a sniffer,
but the sort of
people who would screw with my systems probably wouldn't.


On Mon, Nov 23, 2009 at 4:40 PM, Krzysztof Halasa <khc at pm.waw.pl> wrote:
> I'm not talking about reducing security. su, sudo are already suid root
> (on most systems at least, especially su). Yes, this is, or at least may
> be, a security risk. Admin entering root's password in insecure session
> to install software is another security risk. That obviously doesn't
> mean I want non-root users to install system software at will.

Though this isn't necessary. A facility to obtain elevated authority could be
provided which eliminates this risk.

> I just say that when it comes to entering the root password (and/or
> installing system software), it should be done in a secure manner,
> preferably not from within user X session (unless the risk = the fact
> of user = root equivalency is explicitly and specifically understood
> and accepted).

Sorry— I thought you were taking the further position that because entering
the password is also a risk, that it's okay to simply give subsets of privileged
to users.  You're correct. It's a risk which should and can be eliminated.