DevHeads.net

PackageKit policy: background and plans

I wanted to provide an update to the list on the current thinking about
the PackageKit policy issue from the perspective of the people working
on the core desktop packages and on the desktop user experience.

There was informal meeting earlier today with Richard Hughes, and
myself, and a couple of people who could provide help with big-picture
Fedora issues like Bill Nottingham and Jesse Keating, to try and figure
out if there were obvious steps to take in the short term.

Obviously there are lots and lots of people who care deeply about this,
and there are discussions that need to continue, but with the delay in
getting packages built, tested, and pushed out, we thought there were
advantages to jump-starting things. If there was something obvious, then
it made sense for the package maintainer (Richard) to just do it.

I'm writing this mail somewhat by default: the people who really matter
are the maintainers of the relevant packages, but Richard has gone to
bed, and David Zeuthen and Matthias Clasen are on vacation this week.
I'll try to reflect what they would say; much of it is certainly my own
personal take on things instead.

- Owen

Where the Fedora 12 policy came from
====================================

In Fedora 9, 10, and 11, the first time a user tried to install a
package from the Fedora repositories, they would be prompted for a root
password, with a checkbox to remember that permission for the future.
(Before Fedora 9, you had to enter the root password every time.)

We weren't really fully happy with this; this was basically asking the
user to construct their own security policy. And not only that, but do
it dialog-by-dialog, permission-by-permission as they tried to set up
their Fedora system and get on with their life.

dialogs:

+-------------------------------+
| |
| < A complicated explanation > |
| |
| Root password [ ] |
| |
| [ OK ] |
+-------------------------------+

is that you are training users to blindly enter the root password and
hit OK, *not* something that enhances the overall security of the
system.

There is an obvious better way to do this, which is to figure out
what the appropriate roles are for the system: adminstrative users,
non-adminstrative users, etc., and let the person maintaining system
decide who gets what role.

So, David Zeuthen did a major redesign of PolicyKit to move it from
the old "remembered permissions" policy, to a model where users could be
assigned different roles. See:

<a href="https://www.redhat.com/archives/fedora-desktop-list/2009-August/msg00103.html" title="https://www.redhat.com/archives/fedora-desktop-list/2009-August/msg00103.html">https://www.redhat.com/archives/fedora-desktop-list/2009-August/msg00103...</a>

For some more details about how it works.

The idea was that the change in PolicyKit would be accompanied by a
default set of roles, and a nice user interface for assigning users to
roles. Unfortunately, with the constraints of time, it became clear that
this all (and especially the GUI) wasn't going to be there for Fedora
12. So, PackageKit needed a fixed policy for all users. For each action
(install signed packages, install unsigned packages, remove packages,
etc.), it needed to allow, deny, or ask for the root password.

Among the decisions Richard made was allowing all users to install
signed packages from the Fedora repositories. This was clearly the right
behavior for the common case of a single-user system, where the only
user is also the administrator. And it seemed pretty safe: Fedora isn't
supposed to have packages in it that are dangerous to install. (For
example, by policy, all network services must be off by default and not
enabled by simply installing a package.)

The reaction (why that probably wasn't the best choice)
=======================================================

There's obviously been a lot of feedback on this list and in other
forums about this approach. And a lot of good points have brought up.

Probably the most important one is a bit obvious in hindsight: Fedora is
used on a wide variety of systems, and in some of those - like a shared
home system with parents and young children, or like a computer lab
system - there are some users who shouldn't be able to change what is
installed on the system. Even if installing those packages isn't a
security hole.

The other thing that is clear from the discussion is that we didn't do
nearly enough communication about the change. I think was partly because
the changes *weren't* finished. A rewrite of PolicyKit wasn't a feature
in itself; the feature would have been the accounts dialog, which we
didn't do for Fedora 12. But clearly the changes we did do had some
major impacts that needed to be advertised.

And while there are great low-level docs with all the details about
PolicyKit configuration (see polkit(8) for a starting point to the
docs), we didn't have the simple instructions for changing basic system
policy.

Moving forward from here
========================

After talking things through a bit, the consensus was that we need to
take a course that's conservative for Fedora 12. To do something that
is safe for almost all uses of Fedora, if a bit less convenient.

So, what Richard is planning is an update to PackageKit that changes the
policy so that the root password will be required for package
installation. We should have this out in fedora-updates quite soon;
hopefully tomorrow.

Once we get that out, we'll also make sure that there is documentation
available about how you can configure some users to be able to install
software without having to type the root password every time.

In upcoming Fedora releases, we expect to finish both the default set of
policy roles and the user interface components to provide the full
experience that was originally planned.

Executive summary
=================

We'll make an update to the F12 PackageKit, so that the root password is
required to install packages.

Comments

Re: PackageKit policy: background and plans

By Matthias Clasen at 11/23/2009 - 14:21

[...]

Wow, I go on vacation for a week, and as a welcome-back-present I get
this 1000+-message monster thread :-)

Thanks for filling in for me so eloquently, Owen. I thought I should
follow up and provide some more clarifications on the changes that have
happened in PolicyKit and where we hope to get to, user-experience-wise.

First of all, you should realize that the PolicyKit in F12 is quite
different from the one in F11, which should already be apparent from the
package name change (from PolicyKit to polkit). Many of the changes that
happened on the way are about making PolicyKit more 'enterprise-ready'
and maintainable:

1) The daemon has been refactored to allow separate backends. PolicyKit
itself ships a 'local files' backend, but all the infrastructure is in
place to write a backend that e.g. determines its policy by talking to a
directory server.

2) The 'action definitions' (in /usr/share/polkit-1/actions/) have been
separated from the policy itself (in /var/lib/polkit-1/localauthority/).

3) Policy for the 'local files' backend can easily be overridden on a
site-, org- or, local- granularity.

4) Policy for the 'local files' backend can be defined based on group
membership.

4) There is quite a bit of useful documentation in polkit(8) and
pklocalauthority(8). Docs could of course always be improved, but David
has every reason to be proud of the amount of work he invested in the
polkit docs, in my opinion.

Then there have been a few changes where things in PolicyKit 0.9 were
just not quite right:

5) Retained authorizations have already been discussed as a somewhat
questionable feature. It also leads to awkward UI (nested checkboxes),
so these have been removed.

6) polkit-gnome-authorization was really not a usable tool to configure
policy. At best, it was a debug tool. It has been removed.

If people are desperate to have a similar policy tweak tool back, it is
certainly possible to implement one for the local files backend (it
doesn't really make sense for e.g. a directory server backend), but that
is not our priority.

Our plan for policy configuration is, as Owen explained, is to ship a
default set of roles and have a simple user interface that allows to
assign roles to users. The roles will use the ability of the local files
backend to define group-based policy. In fact, we already have a package
defining such roles: polkit-desktop-policy.

The one thing that we did not get done for F12 is the user interface
that allows to easily assign roles to users. The plans for that are
outlined here:
<a href="http://www.fedoraproject.org/wiki/Features/UserAccountDialog" title="http://www.fedoraproject.org/wiki/Features/UserAccountDialog">http://www.fedoraproject.org/wiki/Features/UserAccountDialog</a>

Once we have roles in place, the package defaults for authorizations
(i.e. what gets installed in the .policy files) should be changed to be
very restrictive.

Matthias

Re: PackageKit policy: background and plans

By Adam Miller at 11/20/2009 - 01:32

Thank you greatly for the well worded and well thought out response/update
on the situation. In a thread of what was essentially a flame war, it is
nice to see something constructive and meaningful emerge from the ashes.

-Adam (From Android - CM)

I wanted to provide an update to the list on the current thinking about
the PackageKit policy issue from the perspective of the people working
on the core desktop packages and on the desktop user experience.

There was informal meeting earlier today with Richard Hughes, and
myself, and a couple of people who could provide help with big-picture
Fedora issues like Bill Nottingham and Jesse Keating, to try and figure
out if there were obvious steps to take in the short term.

Obviously there are lots and lots of people who care deeply about this,
and there are discussions that need to continue, but with the delay in
getting packages built, tested, and pushed out, we thought there were
advantages to jump-starting things. If there was something obvious, then
it made sense for the package maintainer (Richard) to just do it.

I'm writing this mail somewhat by default: the people who really matter
are the maintainers of the relevant packages, but Richard has gone to
bed, and David Zeuthen and Matthias Clasen are on vacation this week.
I'll try to reflect what they would say; much of it is certainly my own
personal take on things instead.

- Owen

Where the Fedora 12 policy came from
====================================

In Fedora 9, 10, and 11, the first time a user tried to install a
package from the Fedora repositories, they would be prompted for a root
password, with a checkbox to remember that permission for the future.
(Before Fedora 9, you had to enter the root password every time.)

We weren't really fully happy with this; this was basically asking the
user to construct their own security policy. And not only that, but do
it dialog-by-dialog, permission-by-permission as they tried to set up
their Fedora system and get on with their life.

dialogs:

+-------------------------------+
| |
| < A complicated explanation > |
| |
| Root password [ ] |
| |
| [ OK ] |
+-------------------------------+

is that you are training users to blindly enter the root password and
hit OK, *not* something that enhances the overall security of the
system.

There is an obvious better way to do this, which is to figure out
what the appropriate roles are for the system: adminstrative users,
non-adminstrative users, etc., and let the person maintaining system
decide who gets what role.

So, David Zeuthen did a major redesign of PolicyKit to move it from
the old "remembered permissions" policy, to a model where users could be
assigned different roles. See:

<a href="https://www.redhat.com/archives/fedora-desktop-list/2009-August/msg00103.html" title="https://www.redhat.com/archives/fedora-desktop-list/2009-August/msg00103.html">https://www.redhat.com/archives/fedora-desktop-list/2009-August/msg00103...</a>

For some more details about how it works.

The idea was that the change in PolicyKit would be accompanied by a
default set of roles, and a nice user interface for assigning users to
roles. Unfortunately, with the constraints of time, it became clear that
this all (and especially the GUI) wasn't going to be there for Fedora
12. So, PackageKit needed a fixed policy for all users. For each action
(install signed packages, install unsigned packages, remove packages,
etc.), it needed to allow, deny, or ask for the root password.

Among the decisions Richard made was allowing all users to install
signed packages from the Fedora repositories. This was clearly the right
behavior for the common case of a single-user system, where the only
user is also the administrator. And it seemed pretty safe: Fedora isn't
supposed to have packages in it that are dangerous to install. (For
example, by policy, all network services must be off by default and not
enabled by simply installing a package.)

The reaction (why that probably wasn't the best choice)
=======================================================

There's obviously been a lot of feedback on this list and in other
forums about this approach. And a lot of good points have brought up.

Probably the most important one is a bit obvious in hindsight: Fedora is
used on a wide variety of systems, and in some of those - like a shared
home system with parents and young children, or like a computer lab
system - there are some users who shouldn't be able to change what is
installed on the system. Even if installing those packages isn't a
security hole.

The other thing that is clear from the discussion is that we didn't do
nearly enough communication about the change. I think was partly because
the changes *weren't* finished. A rewrite of PolicyKit wasn't a feature
in itself; the feature would have been the accounts dialog, which we
didn't do for Fedora 12. But clearly the changes we did do had some
major impacts that needed to be advertised.

And while there are great low-level docs with all the details about
PolicyKit configuration (see polkit(8) for a starting point to the
docs), we didn't have the simple instructions for changing basic system
policy.

Moving forward from here
========================

After talking things through a bit, the consensus was that we need to
take a course that's conservative for Fedora 12. To do something that
is safe for almost all uses of Fedora, if a bit less convenient.

So, what Richard is planning is an update to PackageKit that changes the
policy so that the root password will be required for package
installation. We should have this out in fedora-updates quite soon;
hopefully tomorrow.

Once we get that out, we'll also make sure that there is documentation
available about how you can configure some users to be able to install
software without having to type the root password every time.

In upcoming Fedora releases, we expect to finish both the default set of
policy roles and the user interface components to provide the full
experience that was originally planned.

Executive summary
=================

We'll make an update to the F12 PackageKit, so that the root password is
required to install packages.

Re: PackageKit policy: background and plans

By James Morris at 11/20/2009 - 01:09

I don't think this is clearly the right behavior at all.

Many users limit their use of the root account to essential system
maintenance, and run general purpose applications as a regular
unprivileged user.

This greatly limits the attack surface, i.e. the number of different ways
in which a system might be compromised. System tools are also often more
carefully designed, less complex, better tested, and better reviewed.

I would usually not, for example, run a web browser as root, because it
exposes a fairly complicated application to the global network. A bug in
the browser's HTML parser might allow a remote attacker to take control
of my shell session with an appropriately crafted page.

I think it's fair to say that having this happen as root would generally
be worse than it happening as an unprivileged user. For the latter, the
attacker would need to also then succeed with a local privilege escalation
attack to the same effect.

With the new behavior, the attack surface is increased in several ways:

- The local session has a new means to execute in a high privilege
context, i.e. that which is required to install the system itself.
This is a problem alone -- everything which runs in this context is
now a prime attack target.

- The local session can now install any signed packages from the Fedora
repos:

- I think this includes old versions of packages (correct?) with known
and undisclosed vulnerabilities (old packages are particularly
problematic because they're unmaintained)

- It certainly includes all previously uninstalled current packages

- Packages are installed globally, so the attack surface extends to
other users who may end up using them (like root, or httpd), and not
just the local user at the time

MAC policy can be updated without administrative privilege, breaking our
MAC model in a fundamental way.

There are also several DoS scenarios.

Software always has bugs, and some of those bugs will inevitably be
security-relevant. Ideally, no packages will be dangerous to install, but
we know that some will be.

It is best practice to only install the packages which need to be
installed, for this reason.

Good.

Also good :-)

Thanks for getting this resolved so quickly.

- James

Re: PackageKit policy: background and plans

By Bill Nottingham at 11/20/2009 - 12:07

James Morris (<a href="mailto: ... at namei dot org"> ... at namei dot org</a>) said:

Incorrect.

I'm fairly sure that's wrong as well. Installation of another policy
does not override the current one.

Bill

Re: PackageKit policy: background and plans

By James Morris at 11/20/2009 - 22:36

What about when the system is rebooted?

One scenario here is where the admin has made local modifications, which
are then discarded by an upgrade of the policy. It should not be
possible.

Re: PackageKit policy: background and plans

By Bill Nottingham at 11/23/2009 - 13:18

James Morris (<a href="mailto: ... at namei dot org"> ... at namei dot org</a>) said:

Your complaint appeared to be that someone could switch from
targeted to minimal (or similar) by simply installing the other
package. It *does not work that way*, and it never has.

If you're saying that an upgrade to a later targeted policy might
break the local customizations, doesn't that mean the targeted policy
maintainer made a mistake?

Bill

Re: PackageKit policy: background and plans

By James Morris at 11/23/2009 - 18:02

Possibly (it could simply be that an updated policy is weaker for some
reason) -- but it doesn't matter, there should be no way to change MAC
policy without MAC privilege.

- James

Re: PackageKit policy: background and plans

By Colin Walters at 11/23/2009 - 18:32

It'd be nice here if we had the ability to only grant the ability to
install applications, not packages. We could possibly do this even
now inside PackageKit by always downloading the filelists data, and
looking for a .desktop file. It'd be even better if we could get at
the data inside the .desktop file, but that's not necessary for this.
That leaves aside the packagekit-command-not-found feature for unix
binaries, but that's more of a technical use case.

Re: PackageKit policy: background and plans

By James Antill at 11/24/2009 - 11:24

"applications" is still way too broad, IMO. Even if you limit it to
what I assume you meant, "Desktop applications", it's not obvious that
is good enough.

A useful end goal seems more likely to be something like "allow 'local'
users to update/install signed/trusted versions of: fonts, codecs,
themes, games, editors". For bonus points you could make it possible for
them to remove packages they have installed.
If done well this should even allow things like the "webadmin" role
being allowed to update/install apache related packages.

Re: PackageKit policy: background and plans

By Dominik 'Rathan... at 11/24/2009 - 11:33

I can imagine an additional drop-down list of "user roles" on the user
account creation screen in firstboot GUI. What you described above would
be a "home user". However, parents may not want to let their kids install
all the games they can from Fedora software collection, so we'd also need
some tool to manage allowed root-level actions associated with these roles.
Looks like a kind of enhanced sudo to me. ;)

Regards,
R.

Re: PackageKit policy: background and plans

By Seth Vidal at 11/24/2009 - 11:27

See, this is the problem, with all the exceptions you'd need to
codify it would make much more sense to document how to set them up and
make it relatively easy to do so that the local admin can do so. Think of
it like documentation for sudo but with docs that don't make everyone cry.

-sv

Re: PackageKit policy: background and plans

By James Antill at 11/24/2009 - 13:37

Oh, I agree 100%. My bad for not explaining what I meant. I'm not
saying the GUI pkg installer should come with the above as defaults,
just that it should work towards being able to "easily" provide the
above functionality.

Re: PackageKit policy: background and plans

By Seth Vidal at 11/23/2009 - 19:32

Or - you could more easily generate the 'which pkgs have .desktop files'
and propagate that into a package Provides.

since yum can install by provides - that takes care of that need.

example:

Provides: App('foo')

-sv

Re: PackageKit policy: background and plans

By Frank at 11/24/2009 - 23:50

Would it be possible to do this similarly to Conary... only installing
the files (.so's and things in /etc and /usr/share/{icons,sounds,...}
etc) required by a given application (binary with .desktop file) ?

This would provide similar to package splitting, but because of version
control and something like google update, it can be effective to update
only those files and applications when its parts are updated upstream...
with something like presto only bringing in what changed, and something
like jigdo allowing you to download each file from a different mirror,
speeds can be quite quick and downloads quite small.

Re: PackageKit policy: background and plans

By Seth Vidal at 11/25/2009 - 00:06

That would require massive changes to rpm.

it is not an undertaking that is likely to happen in my opinion.

-sv

Re: PackageKit policy: background and plans

By Panu Matilainen at 11/24/2009 - 03:27

We're already collecting provides from .desktop files for mime types,
adding more provides would be a no-brainer.

Re: PackageKit policy: background and plans

By Matthew Garrett at 11/20/2009 - 10:34

I know basically nobody who, on a generally single user system,
explicitly switches to a console to log in as root and perform package
installs there. If you're not doing that then the issue is basically
moot - a user-level compromise will become a root-level compromise the
next time you run anything as root.

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 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.

Re: PackageKit policy: background and plans

By James Morris at 11/20/2009 - 22:19

This is how I started doing things in 1993, although I changed to sudo a
few years back.

I never tick those boxes. I'd like to know how to get rid of them
entirely.

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.

- James

Re: PackageKit policy: background and plans

By Kevin Kofler at 11/22/2009 - 19:12

Upgrade to F12 (with the latest PackageKit update), there's no such checkbox
in F12's PolicyKit.

Kevin Kofler

Re: PackageKit policy: background and plans

By Krzysztof Halasa at 11/23/2009 - 10:37

Kevin Kofler <kevin. ... at chello dot at> writes:

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.

Re: PackageKit policy: background and plans

By Gregory Maxwell at 11/23/2009 - 14:24

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.

Re: PackageKit policy: background and plans

By Krzysztof Halasa at 11/23/2009 - 17:40

Gregory Maxwell < ... at gmail dot com> writes:

I didn't suggest anything like that, did I?

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.

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).

Re: PackageKit policy: background and plans

By Peter Jones at 11/23/2009 - 15:13

Wait, you're arguing for this *instead* of finer-grained elevations of privilege
governed by policy files which can be locally overridden safely?

I think you've characterized things backwards here.

Re: PackageKit policy: background and plans

By Gregory Maxwell at 11/23/2009 - 19:06

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.

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.

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

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.

Re: PackageKit policy: background and plans

By Jesse Keating at 11/23/2009 - 19:43

This is precisely the dialog that has been removed from F12 and is not
planned to be returned.

Re: PackageKit policy: background and plans

By Gregory Maxwell at 11/23/2009 - 20:01

My understanding was that this was removed because collecting the root password
during a user session is insecure because there could be a sniffer or the dialog
could be faked.

If I understand you correctly you are saying that even if this weakness were
addressed (e.g. through whatever means make fast user switching secure) that
the feature would not be re-introduced. Am I misunderstanding?

If I am not misunderstand, can you point me to the real reason that this feature
was removed?

Thanks!

Re: PackageKit policy: background and plans

By Peter Jones at 11/24/2009 - 15:22

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.

The way around this is role-based privileges, which is what polkit is
implementing - it means that for some actions, the user is automatically
authorized by being assigned a role (for some actions, that is by being a
member of the desktop_admin_r group). For some actions, the user may need
to prove that he's who he says by entering /his/ password, but not the root
password. The user does not thus get trained to enter the root password
into dialog boxes.

The important part here is that there's granularity on the actions - it's not
"assume root access", it's "assume access to start $task that performs $action",
so a) if the fake dialog attack does occur, it's a password with limited
abilities which gets betrayed, and b) the admin is not necessarily giving
free reign to the user in the first place.

The model here is actually pretty good. The policy was clearly not what
it should have been, and documentation/communication of the various
roles and the rollout plan could have been better. Though tbf, on the polkit
side there's plenty of "how this works" documentation that is useful and
thorough; the communication of the roles and associated policy itself,
that is, how PackageKit is using polkit and what admins need to know
to lock a machine down, is what I'm talking about.

I don't understand what it is you think fast user switching does. You're just
logged on as a different user. It's just like being logged in with a different
getty on tty2 than on tty1.

Re: PackageKit policy: background and plans

By James Antill at 11/24/2009 - 16:49

Sure, that's _a_ problem ... assuming the user has been trained. But
that's a _big_ assumption, esp. when we are only talking about
installing _new_ packages (doesn't happen often, so the user isn't
trained to accept 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).

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¹.
But suggesting that whatever polkit is configured to use is
automatically better than auth_as_root is, at best, misleading.

Personally I don't think _anyone_ knows "how to make a usable and thus.
in practice secure desktop". So some of the comments I've read saying
basically "We know X is insecure, so we are now using Y which is
secure/better" are not helping (in fact I'd suggest that this mindset is
what lead to this problem initially).

¹ Noting that polkit force removed the "remember auth" option, for no
particularly sane reason that I've seen ... so if that option turns out
to be "the best" option, then role-based privileges has (at least
currently) hurt security.

Re: PackageKit policy: background and plans

By Peter Jones at 11/24/2009 - 17:15

That's what I said, yes.

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.

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

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.

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.

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.

Re: PackageKit policy: background and plans

By Adam Williamson at 11/24/2009 - 10:56

Your understanding is not correct. The 'feature that was removed' is
retention of authorizations (for more than a very short period).
PolicyKit 0.x had keep_always policies, which asked a user to
authenticate for an operation just once and then kept that authorization
indefinitely. These are what were removed in PolicyKit 1.x, leaving only
the keep policies, which retain authorization for just a few minutes.

Re: PackageKit policy: background and plans

By Matthew Garrett at 11/21/2009 - 19:38

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 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.

Re: PackageKit policy: background and plans

By Stephen John Smoogen at 11/20/2009 - 22:43

I also do it. I usually use the graphical tool once or twice a release
and then find myself not able to do something that yum lets me do
automatically so go back to just yum. Then again I have been doing it
this way for about as long as James Morris. I find myself completely
frustrated trying to do stuff on a Mac or Windows box when the gui is
just spinning and I have no idea a) is it installing, b) is it
crashing etc.

I agree.. the corporate/government places I have dealt with usually
have to hack the code to get rid of it because it violates so many
policies its not funny.

I think the vast majority of users would love everything to run like
it was under Windows95 when you could just click on something and it
worked without a password or login or anything. For the envisioned
'desktop' model is there a reason to have multiple users for the
default? Is there a reason to have anything but root?

Actually I am asking this in seriousness versus grumpiness. A general
security policy needs to know why certain things are set beyond
ancient Unix history.

Re: PackageKit policy: background and plans

By Matthew Garrett at 11/21/2009 - 19:42

The reason I find it hard to believe that this practice is the standard
one even amongst traditional UNIX users is that if it were, there'd be
no SUID bit on the su binary.

Yes. There's a range of acts that root is able to perform that even an
admin user should not be able to perform without extra authentication.
It's not even necessarily related to security - I don't want a bug in
firefox resulting in it trying to write to /dev/sda rather than a file
in my home directory, for instance.

Re: PackageKit policy: background and plans

By James Morris at 11/22/2009 - 18:58

This needs to be enforced at the OS level, with an analyzable policy, so
you can determine if this is possible or not. "Install all signed
packages from a Fedora repository" may indeed include the ability to write
to /dev/sda -- nobody really knows and you have no way to find out.

Also, it should certainly be possible while the operation is running at
full privilege.

- James

Re: PackageKit policy: background and plans

By Krzysztof Halasa at 11/21/2009 - 22:20

Matthew Garrett < ... at redhat dot com> writes:

Su with suid is a security risk, removing the suid bit is a normal
practice for me.

Re: PackageKit policy: background and plans

By Jeff Garzik at 11/20/2009 - 22:28

Agreed. Speaking even more generally, it seems we have abandoned the
"default to secure" principle.

Jeff

Re: PackageKit policy: background and plans

By Adam Williamson at 11/21/2009 - 00:52

just keep echoing back and forth like that and you'll be firmly
convinced the world is ending tomorrow.

the thesis seems quite comprehensively destroyed by, uh, the fact that
we changed the policy. if no-one cared about the default to secure
principle, why would we have changed anything?

please don't extrapolate to absurdity, here.

Re: PackageKit policy: background and plans

By Robert Marcano at 11/20/2009 - 12:20

I do that on critical workstations because a long time ago an old
(fixed) bug killed my X session when updating and messed my system, so I
do not trust too much updating base X components using a GUI. on my
personal systems, yes I use the GUI method

Re: PackageKit policy: background and plans

By Owen Taylor at 11/20/2009 - 12:41

This actually is one of the big advantages of PackageKit - because the
installation is being done by a daemon rather than a process running in
your session, if the X session dies during package installation, you
won't be left with a half-completed transaction.

Though that only helps from the command line if you use
gpk-install-package-name rather than yum. Probably not too many people
do that :-)

- Owen

Re: PackageKit policy: background and plans

By Seth Vidal at 11/20/2009 - 13:33

if you install from the command line using yum and you're worried about
the install obliterating your X session I would recommend using screen.

-sv

Re: PackageKit policy: background and plans

By Frank Ch. Eigler at 11/20/2009 - 13:00

To what extent are yum/rpm/packagekit "transactions" databasey enough
so that they can actually be undone if the machine or process crashes
midstream?

- FChE

Re: PackageKit policy: background and plans

By Seth Vidal at 11/20/2009 - 13:34

not enough. We can sometimes recover - it really depends on where it died
:(

-sv

Re: PackageKit policy: background and plans

By Fulko Hew at 11/20/2009 - 10:38

I do! And I tell everyone else too, so they learn/understand the difference
between 'god' and a 'mere mortal user' (ie. root and anyone else).

... snip ...

Re: PackageKit policy: background and plans

By Matthew Garrett at 11/20/2009 - 11:24

Actually, thinking about it, even this isn't sufficient. An attacker
could change the ctrl+alt+F* bindings and use them to pop up a
full-screen window that looks like the console. So you'd also need to
set up securetty to ensure that root can only log in on real consoles.
I really don't see this being a security issue in the common single-user
case.

Re: PackageKit policy: background and plans

By James Morris at 11/20/2009 - 22:34

Right. This is why we need trusted path (not just for consoles, but for
interaction generally between users and the system).

The fundamental requirements for securing our systems were outlined in a
paper by NSA researchers - "The Inevitability of Failure: The Flawed
Assumption of Security in Modern Computing Environments"

<a href="http://www.nsa.gov/research/_files/publications/inevitability.pdf" title="http://www.nsa.gov/research/_files/publications/inevitability.pdf">http://www.nsa.gov/research/_files/publications/inevitability.pdf</a>

I strongly recommend that Fedora developers read this.

Some of the requirements have been addressed since the paper was published
(mostly in the area of adding Mandatory security via SELinux), although
the desktop in particular still needs work. There's been some progress,
e.g. XACE, which allows us to begin locking down the X itself (a video of
the LPC session on this is at <a href="http://video.linuxfoundation.org/video/1566" title="http://video.linuxfoundation.org/video/1566">http://video.linuxfoundation.org/video/1566</a>).

I was hoping to see more desktop and general OS developers at the security
track of LPC -- it was mostly security folk talking to other security
folk. Certainly, I think we should try and find a way to get more
discussion happening amongst different groups next time.

FWIW, I discussed the "inevitability" requirements as part of a broader
talk on Linux security at KCA in Brisbane earlier this year; video &
slides are online:

<a href="http://namei.org/presentations/linux-kernel-security-kca09.pdf" title="http://namei.org/presentations/linux-kernel-security-kca09.pdf">http://namei.org/presentations/linux-kernel-security-kca09.pdf</a>
<a href="http://www.ustream.tv/recorded/1814752" title="http://www.ustream.tv/recorded/1814752">http://www.ustream.tv/recorded/1814752</a>

Re: PackageKit policy: background and plans

By Conrad Meyer at 11/20/2009 - 01:26

On the contrary. On the typical single user system, it's just as bad if an
attacker can steal / delete / modify the user's files as it is if the attacker
can modify / delete system files. Privilege escalation isn't needed to delete
everything the single user cares about.

Regards,

Re: PackageKit policy: background and plans

By Gregory Maxwell at 11/20/2009 - 09:52

Not quite. For example, it's much easier to fix a system which has only had a
user account compromised, since if you actually trust that its only the user
account you can skip the full reinstall.

This is also assuming a strictly single user system. With features like fast
user switching it wouldn't be inadvisable or especially inconvenient to operate
business and pleasure activities from separate accounts. I don't know anyone
that does this today, but as it becomes easier to do so and if the systems don't
continue to go down the route of giving the local accounts root access then it
may be a practice which becomes common.

Re: PackageKit policy: background and plans

By Conrad Meyer at 11/20/2009 - 15:47

wrote:

It's easier to fix the system, *if* you trust that only the user account has
been compromised. However, to the user (and remember we're talking about
single-user systems here), their data is much more important than system
files. You can get system files back -- just reinstall. If data is lost /
mangled / stolen, you can't get that data or privacy back.

Yes, we're talking only about single user systems, let's not get off-track
here.

Regards,

Re: PackageKit policy: background and plans

By James Morris at 11/20/2009 - 04:33

Note that I said generally.

In the specific case where the attacker only wants access to the user's
files, can exploit an existing vulnerability to do so, and can also get
the data back out without further privilege (if they want the data), then
yes, it's game over at that point.

There are many possible scenarios where an attacker would want more
privileged access to the system, e.g. install rootkits/firmware kits,
modify firewall settings, run network services, attack other systems,
evade detection etc. IOW, the current landscape of windows malware,
data-stealing worms, botnets and so on.

Getting root access is much more valuable in the general case.

There are also the separate issues, as I mentioned subsequently, of
increasing the attack surface, breaking the MAC model, and executing at
full system privilege (also, without further authorization).

I think we're throwing away a lot of well-established security benefit in
moving away from the simple model of using a root/wheel account (or sudo)
for admin and a separate user account for everything else.

- James

Re: PackageKit policy: background and plans

By Conrad Meyer at 11/20/2009 - 15:45

I agree with this.