|
|
Log in / Subscribe / Register

Fedora 12 lets unprivileged users install packages

[Posted November 18, 2009 by corbet]

Fedora bug #534047 contains an interesting Fedora 12 surprise: "PackageKit allows you to install signed content from signed repositories without a password by default. It only asks you to authenticate if anything is unsigned or the signatures are wrong." So any user can install any package found in the official repository. Some Fedora developers, at least, seem to see this as a feature; see this rapidly-growing thread for the discussion.

The bug report contains the incantation needed to disable this behavior: 

    pklalockdown --lockdown org.freedesktop.packagekit.package-install

Evidently that is not a long-term solution, though; see this post for a rather more involved fix. Stay tuned: we'll probably post a longer look at this issue in the near future.

to post comments

Fedora 12 lets unprivileged users install packages

Posted Nov 18, 2009 23:53 UTC (Wed) by midg3t (guest, #30998) [Link] (12 responses)

This should make local privilege escalation a little easier.

1. Find package with recent, unpatched privilege escalation vulnerability.
2. Install package.
3. Exploit privilege escalation vulnerability.
4. Profit!

Haystack surrounding a needle.

Posted Nov 19, 2009 0:30 UTC (Thu) by sladen (guest, #27402) [Link] (10 responses)

If they are a local user they already had root by way of phsyical access, so fair enough.

But for a remote user, life got easier; one no longer needs to find a hole in the actual running system or available setuid software; but merely in the (somewhat less tested) package-specific install scripts.

The problem just changed from trying to find a needle in a haystack, to one of spotting a haystack surrounding a needle.

Haystack surrounding a needle.

Posted Nov 19, 2009 0:55 UTC (Thu) by etrusco (guest, #4227) [Link]

The summary says "signed packages" . I didn't RTFT (thread) either, but I'm hoping this capability will only be enabled by default to some kind of "desktop users" or "interactive users"?

Haystack surrounding a needle.

Posted Nov 19, 2009 0:55 UTC (Thu) by jspaleta (subscriber, #50639) [Link] (8 responses)

lets be clear... remote users aren't privledged by default. PolicyKit understands the concept of console user versus remote.

-jef

Haystack surrounding a needle.

Posted Nov 19, 2009 1:23 UTC (Thu) by sbergman27 (guest, #10767) [Link] (7 responses)

"""
lets be clear... remote users aren't privledged by default. PolicyKit understands the concept of
console user versus remote.
"""

Does it understand the concept of "local dinner parties" vs "remote dinner parties"? "Local
children" vs "remote children"?

Has anyone looked into how well this kind of thinking worked for Windows?

Haystack surrounding a needle.

Posted Nov 19, 2009 7:29 UTC (Thu) by bronson (subscriber, #4806) [Link] (6 responses)

Does any operating system understand the concept of "local dinner parties"?

Haystack surrounding a needle.

Posted Nov 19, 2009 7:46 UTC (Thu) by bronson (subscriber, #4806) [Link] (5 responses)

Oh, I see what you're saying... You're worried that some dinner party guest might log onto your computer and fill your root partition with insecure daemons? Not a problem -- how many Linux users host dinner parties? Maybe if we were using Windows 7 this would be an issue: http://www.youtube.com/watch?v=1cX4t5-YpHQ (it's real, sorry, only watch if you have a strong constitution)

For the record I agree: it seems utterly daft to have this enabled by default. Did we forget the lesson from RH6 having a bunch of unnecessary daemons (read: breakin vectors) enabled by default?

Haystack surrounding a needle.

Posted Nov 19, 2009 9:06 UTC (Thu) by mjthayer (guest, #39183) [Link] (4 responses)

Hm, Gnash used to be able to cope with some youtube videos, but recently I have had a zero success rate. Not that it is killing me, but still... Anyone else?

Haystack surrounding a needle.

Posted Nov 19, 2009 15:31 UTC (Thu) by geisler (guest, #44380) [Link]

They switched the default player to Flash 10, but I've still been able to see success by clicking on the icon that opens the video in a new window. For some reason, that video will run while the one on the page will not.

Haystack surrounding a needle.

Posted Nov 19, 2009 17:24 UTC (Thu) by sir99 (guest, #3286) [Link] (2 responses)

Flash works so poorly on my system that I use youtube-dl and watch in mplayer. Probably there's a firefox extension to do this more transparently.

Haystack surrounding a needle.

Posted Nov 19, 2009 19:35 UTC (Thu) by drag (guest, #31333) [Link]

clive + mplayer works for me.

Haystack surrounding a needle.

Posted Nov 19, 2009 20:39 UTC (Thu) by SEJeff (guest, #51588) [Link]

Install the ant.com download toolbar. It works very well.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 0:31 UTC (Thu) by kragil (guest, #34373) [Link]

My thought exactly, but this is a single user desktop feature and not for servers.

I like it.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 0:46 UTC (Thu) by dskoll (subscriber, #1630) [Link] (9 responses)

Wow. The Debian OpenSSL fiasco left many a red-faced Debian developer and user, and made me wonder about my decision to choose Debian.

Looks like the Fedora crowd now have their very own WTF, so I don't feel so bad.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 0:59 UTC (Thu) by airlied (subscriber, #9104) [Link] (8 responses)

No its nothing like that, you are just trying to justify your choice and I've no idea why you felt the need to comment on that.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 12:00 UTC (Thu) by dskoll (subscriber, #1630) [Link] (7 responses)

I felt the need to comment because this is a real WTF. It opens up all kinds of attack vectors.

For example: Many RPMs have scriptlets that run on installation or upgrade. Have any of these scripts been designed to be secure in the face of a malicious local non-root user, who can do things like manipulate the environment, etc? Of course not, because the package maintainers rightly assume that anyone installing a package has root access anyway, so they don't need to protect against the possibility of a local user gaining root access.

This move gives malicious users several thousand new, juicy targets.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 14:34 UTC (Thu) by nevyn (guest, #33129) [Link] (6 responses)

> Many RPMs have scriptlets that run on installation or upgrade. Have any
> of these scripts been designed to be secure in the face of a malicious
> local non-root user, who can do things like manipulate the environment,
> etc?

RPM clears the environment before running scriplets (as I'd assume dpkg does). PackageKit doesn't allow arbitrary bits of the environment to move from it's front end (running as the user) to it's backend (running as root). But, apart from that, thanks for your insightful and informative speculation.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 15:54 UTC (Thu) by dskoll (subscriber, #1630) [Link] (5 responses)

The fact remains that installation scripts are much less likely to have been scrutinized for security problems than the actual packages themselves. Maybe you can't play with environment settings, but being able to run thousands of (let's face it) quickly hacked-together scriptlets as root is very enticing for attackers.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 18:03 UTC (Thu) by mebrown (subscriber, #7960) [Link] (4 responses)

For statistics buffs out there, mean/median/mode:

The mean number of lines of installation scripting for packages installed on my F11 system: 2

The median and mode: 0

By far the most common install script: ldconfig

There are only tens of packages out there with more than a dozen lines of install scripting. (ie. easily auditable) The packaging guidelines discourage complicated install scripting.

I have not audited all the packages out there, but the thought that there are thousands of packages out there with potentially vulnerable install scripting is unfounded in reality.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 19:55 UTC (Thu) by dskoll (subscriber, #1630) [Link] (3 responses)

OK, fine. If you think it's OK to increase the attack surface from a few hundred packages you want installed on your Fedora system to every single signed package in Fedora, then I guess the change makes sense.

For people who are concerned about security, it makes no sense at all.

As a thought experiment, consider how the Fedora community would have reacted had Microsoft made a similar move. They'd have scoffed at its incredible lameness.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 20:36 UTC (Thu) by mebrown (subscriber, #7960) [Link] (2 responses)

Sure, if by "people concerned about security", you mean, "people who have kneejerk reactions with no analysis whatsoever".

Compare/contrast with a theoretical Microsoft action is neither analysis or valid argument. Reading this thread, I'm surprised at the amount of misinformation floating around from *lwn readers*, of all people.

People who have untrusted users can use the locked-down guest account for those users. People who fall outside of normal use case scenarios can easily just change the default to disallow this. Generally anybody who is locking their system down anyways can just add this to the list (or have this as a standard switch that gets de-activated in kiosk mode.)

Personally, after setting up several machines for people who fall under the more general fedora-targeted use-cases, this provides a much better user experience. I'd rather let my wife and mother-in-law install their own software without having to give them complete sudo/root access.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 20:45 UTC (Thu) by jgarzik (guest, #8364) [Link]

It is no theoretical argument to say that secured, multi-user workstations running F11 will upgrade into insecurity, when moving up for F12.

You must (a) be aware of the new F12 PackageKit policy and (b) remove PackageKit after upgrade to avoid this major security hole [from the PoV of a multi-user admin].

How many classrooms, laptops, workstations will even be aware of this, given that this is not mentioned in F12-gold release notes at all?

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 21:19 UTC (Thu) by dskoll (subscriber, #1630) [Link]

Sure, if by "people concerned about security", you mean, "people who have kneejerk reactions with no analysis whatsoever".

*sigh*. I'm not surprised the state of computer security is such a mess. This will come back to bite Fedora, mark my words. "Improving the User Experience" is often (unfortunately) a code phrase for "Security is inconvenient, so let's reduce security."

It's a basic tenet of computer security to reduce your risk by not installing unnecessary software. That's such an obvious best-practice that I'm stunned the Fedora team can't understand the reaction this change is getting.

I'd rather let my wife and mother-in-law install their own software without having to give them complete sudo/root access.

Wow. That's completely opposite to what I do; I would never trust my wife, kids or parents to install software, let alone have any kind of sudo/root access. I manage the machines for them.

The average Windows machine has been designed for an "Improved User Experience" and lets unsophisticated users install software, etc. The average Windows machine is also a cesspool of adware, spyware, trojans and viruses. I'm not implying that the latest Fedora change is that bad, but it's certainly a step in the wrong direction.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 0:53 UTC (Thu) by elanthis (guest, #6227) [Link] (8 responses)

Wheel group. The end. No need to invent more crap
or fancy mechanics to deal with basic security we had solved years ago.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 1:03 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (6 responses)

Wheel group doesn't give you the level of fine grained access PolicyKit does. PolicyKit lets me set a local policy that says I want users in the active session to be able to update the system without a password, install packages with a password and deny package removals by default and deny everything in the remote session.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 2:24 UTC (Thu) by djcapelis (guest, #53964) [Link] (5 responses)

Packagekit should be using PAM to do this. You know, the framework that already does all of those things that you mentioned but the -kit folks didn't bother to reuse it and just expose their policy as a set of PAM service providers?

The OP is right to be angry that he can't use pam_wheel.so to set policy with packagekit in a unified pam.d directory like he can with *every* other tool on his system.

The *-kit projects are often problematic exactly because of this type of destructive need to solve problems by inventing their own (usually inferior) frameworks. All of the policy needs could have been expressed with PAM modules and then we would have had a wonderful unified way to express these types of policies across all kinds of administrative tasks. (PAM is already quite good at these needs.)

But no, we have pklalockdown and /var/lib/polkit-1/localauthority/20-org.d instead.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 2:39 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (4 responses)

PAM is again different from PolicyKit. Start reading from

http://hal.freedesktop.org/docs/PolicyKit/intro-define-pr...

PolicyKit is not a replacement for PAM, Sudo, wheel users or other methods of elevating privileges. Btw, pklalockdown is not in any released version of PolicyKit and is apparently being dropped soon. So pkla files are the recommended way forward as explained in the blog post. The location /var doesn't seem to be a good match and that is being discussed in the development list.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 13:27 UTC (Thu) by fuhchee (guest, #40059) [Link] (3 responses)

"PolicyKit is not a replacement for PAM, Sudo, wheel users or other methods of elevating privileges."

Right, it's just an *additional* way of elevating privileges.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 18:11 UTC (Thu) by drag (guest, #31333) [Link] (2 responses)

It is a attempt to effectly eliminate the need for sudo/su for normal activities as well as provide a way to sanely configure this sort of thing for a administrator.

For example:

Prior to Policykit/DeviceKit type stuff the only way users could mount removable media was to use 'sudo mount' or some similar mechanism. Now you can configure a user's desktop to allow the user account to mount removable volumes.

So lets say your running a corporate network of Linux desktop users and there is a certain class of users that require the ability to mount USB drives for their jobs, for whatever reason.

Using the old way you would have to set up a configuration management system to manage your sudoers configuration and then train your users on how to use sudo. (or have gtksudo or something like that launch stuff on their behalf). And by giving them ability to use sudo your giving them the ability to run root-privileged code under their user account. You can lock down sudo, but it's always a issue.

How, for example, are you going to use sudo to prevent them from remounting a drive in a vulnerable way? How are you going to differentiate between local or network drives or anything like that? You can write shell scripts, but it's trivial to inject code into shell scripts. (which is why the kernel ignores setuid root permissions on scripts). Using Policykit this gives you a saner way to configure policies for groups of users. Right now you'll have to still use a configuration management engine to do it, but in the future it'll support using things like LDAP for configurations. Combining that with Devicekit this allows you to give privileged actions to certain users while still avoiding the pitfalls of giving them (hopefully limited) access to root.

Previously you'd have to be very careful and audit the code of every application you create to run as root to carry out the privileged actions of the user's (since it's running as root under a user's control) to auditing the dbus interfaces for those privileged applications. As long as the daemons and policykit's dbus code is properly secure then this should make your systems much more secure then running gtksudo or sudo or whatever else that gives users root account access.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 18:48 UTC (Thu) by foom (subscriber, #14868) [Link] (1 responses)

Perhaps you didn't know about the "user" option in /etc/fstab that allows unprivileged users to
mount certain devices? That certainly isn't perfect in today's world of dynamically allocated device
names, but it worked quite well before that.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 19:38 UTC (Thu) by drag (guest, #31333) [Link]

Yes if you know what device is going to be mounted prior to mounting it then
you can configure the system ahead of time.

And you are right that it's a poor match with what we have to deal with
today.

That and it's just one of dozens of examples.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 1:06 UTC (Thu) by ofeeley (guest, #36105) [Link]

Except that that basic security doesn't allow trusted, local desktop users to easily install packages. (Read your children or other relatives as a synonym for trusted, local desktop users).

If there is anything to get excited about it's the lack of clear signaling of this change and the lack of simple ways to revert it.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 1:09 UTC (Thu) by cmccabe (guest, #60281) [Link] (3 responses)

Wow. Totally absurd. Apparently you can't remove software this way either, only add it.

The comments are also pretty crazy too. David Zeuthen compares this to automounting storage devices. Hello? Automounting storage devices only happens when I am in the same room as the computer, inserting a new storage device.

So far I haven't seen a single user who asked for this, or thinks it's a good idea. Apparently it's time to forget about using "desktop" spins of Fedora. What's particularly sad is that security is one of the areas where Fedora still has an advantage over Ubuntu.

C.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 1:23 UTC (Thu) by hadess (subscriber, #24252) [Link] (2 responses)

Except that remote users aren't allowed to install packages. You can probably think of a nice beat-down for the rest
of your rant for yourself.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 3:41 UTC (Thu) by jgarzik (guest, #8364) [Link] (1 responses)

That holds true only until the next Web browser bug is found (or pick your own remote user-level exploit -- web browsers are merely the most common attack vector, not the only one).

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 6:49 UTC (Thu) by bojan (subscriber, #14302) [Link]

Exactly. This is madness. If someone is brave enough to _enable_ this kind of stuff on their machine, that's OK. But shipping this as a default is nuts.

PS. Speaking as a long time user of Fedora.

Not a new direction

Posted Nov 19, 2009 1:43 UTC (Thu) by gmaxwell (guest, #30048) [Link] (4 responses)

A while back it was pointed out that the same 'security' facility was permitting non-root users to arbitrarily change the system time. The same voices took that same "but it's a desktop distribution!" and "you can turn it off by running <byzantine command never heard of by any unix admin>" kinds of positions.

What I really don't get is the dichotomy of also shipping SELinux by default which prohibits many things that Unix has classically allowed and can be quite tricky to deal with, even with all the tools Fedora has added, while at the same time giving regular users non-trivial swaths of root access without authentication.

Fedora used to have share a clear and auditable default security policy with most the rest of unixdom. Today it's a fedora specific undocumented mismash which changes from version to version that you have to use windows registry like tools to interact with.

Not a new direction

Posted Nov 19, 2009 1:46 UTC (Thu) by nix (subscriber, #2304) [Link] (3 responses)

Well, it's not Fedora specific; PolicyKit is used by other distros too.

Horribly underdocumented mishmash I agree with. I have no idea how to use
PK: configuring it appears to require bashing largely-undocumented XML
into policy files.

Not a new direction

Posted Nov 19, 2009 1:51 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

For Fedora 12, the following man pages are useful

pklocalauthority(8) polkit(8) polkitd(8) pkaction(1), pkcheck(1), pkexec(1)

It could be better but it is not empty either.

Not a new direction

Posted Nov 19, 2009 1:56 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

Aha. I'd somehow missed pkaction(1), without which everything is very
opaque. TBH though that blog post on changing settings with polkit was
better documentation than ahything I've ever seen with polkit itself...

Not a new direction

Posted Nov 19, 2009 4:15 UTC (Thu) by halfline (subscriber, #31920) [Link]

As mentioned above, have a look at the polkit man page. PolicyKit is actually very well documented. The main polkit man page describes the architecture, gives summaries and links to the tools (including pkaction) and examples for configuring policy. It even has ascii screenshots. To be honest, I haven't come across many projects with better documentation.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 1:54 UTC (Thu) by tonyblackwell (guest, #43641) [Link] (4 responses)

My first look into the Fedora community. In response to user concerns on this issue, the comments from those I think may be senior Fedora people to the users include:
"I don't care"
"There's nothing to discuss here"
"Your rationale appears to be missing"
"before you complain too much"
"You either trust the Fedora repos or you don't"
"It's not insecure"
"the default policy may not be to your taste"

Really gives the user a warm welcome feeling!

I'm used to respectful, relevant and issue-related discussion in the Mandriva bug reporting environment, even if I made some error in having reported an apparent issue.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 2:45 UTC (Thu) by linuxjacques (subscriber, #45768) [Link] (1 responses)

I was reading those replies from the Redhat employees and I kept thinking
"are you people all insane?"

It seems that the best solution for now is 'yum erase PackageKit'

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 12:34 UTC (Thu) by drag (guest, #31333) [Link]

How about thinking:

"Gee these guys may have a point, let me try to figure out why they think
they way they do even if they might be wrong ultimately"

Because they actually do have a point and they actually are not wrong about
it.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 11:52 UTC (Thu) by Tet (subscriber, #5433) [Link]

Yep, that's the real problem here. Not that it was a bad decision (which it plainly was), but that:
  1. A change this significant was slipped in without any real discussion.
  2. RH employees are being completely dismissive of the concerns of the community.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 23:54 UTC (Thu) by sbakker (subscriber, #58443) [Link]

My first look into the Fedora community. In response to user concerns on this issue, the comments from those I think may be senior Fedora people to the users include [...]

Have we been reading the same thread? AFAICT, there was really only one person thinking there was absolutely nothing wrong with the change. What I saw from a few senior Fedora contributors and several Red Hat employees was more of a "this should have been communicated better", "we need to re-think this" and "perhaps we should revert this".

At least the release notes now have a big fat warning in them :-)

Fedora and target audience

Posted Nov 19, 2009 2:02 UTC (Thu) by mattdm (subscriber, #18) [Link]

Can we highlight Seth's blog entry a little more prominently? It's very useful. http://skvidal.wordpress.com/2009/11/18/polkit-and-package-kit-and-changing-settings/.

Honestly, I'm having a hard time getting worked up given last month's discussion on What is Fedora?. Particularly:

We found four defining characteristics that we believe best describe the Fedora distribution's target audience: Someone who (1) is voluntarily switching to Linux, (2) is familiar with computers, but is not necessarily a hacker or developer, (3) is likely to collaborate in some fashion when something's wrong with Fedora, and (4) wants to use Fedora for general productivity, either using desktop applications or a Web browser.

This setting seems completely appropriate for that target.

The right answer is that we need enough people interested in producing solid Fedora Server and Fedora Workstation (as opposed to personal desktop) spins. Enough people with enough time -- I'm definitely interested, but there's no way I have the cycles right now.

Really, the only thing that has me shaking my head is PolicyKit's config file location -- /var/lib, really? At least they're not in dotfiles a la qmail....

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 6:32 UTC (Thu) by gdt (subscriber, #6284) [Link] (6 responses)

Oh dear. The new default is wrong. Consoles used to be in a secure location, but workstations started to make that unlikely and laptops make the idea that the console is more secure than the network totally untenable. If you think about a school, the student is likely to be on the console and the administrator more likely to be accessing the machine across the network.

One of the great advances in security in the past decade has been the wide acceptance that software systems should be secure by default. Which this suggestion isn't. It allows an untrusted user on a console (ie, a student in a computer lab) to easily take advantage of the next local exploit by installing the deficient software before a patch is available from the mirror (and given that Fedora's mirroring really sucks at the moment, that could be days even for a 0-day fix). The idea that the software should be shipped insecurely for computer lab use, and then the default altered by the sysadmin is exactly the sort of thinking which leads to 500 page "deployment manuals" of the type hated by administrators everywhere, and rather reminiscent of the 'sacrifice security for usability' ethos of a major vendor who's deep security issues cost its users billions per year..

Fedora have confused the notions of "trusted to configure hardware because they hold that hardware" and "trusted to administer machine". The first can be checked by seeing if they have physical access to the machine (ie, are logged into the console). The second is a list of user names, typically membership of 'wheel'.

If this means that only system administrators can automagically install codecs and fonts, well so be it. In the common case of a laptop being used by its owner, you're only inconveniencing them by asking them to authenticate.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 6:44 UTC (Thu) by dlang (guest, #313) [Link] (5 responses)

forget the issue of installing packages with the latest zero-day exploits in them

just install packages that grant addtional access to the system by design!

there are a LOT of packages out there that are extremely useful under some conditions, but under other conditions (and frequently with default configs) open up your system

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 9:48 UTC (Thu) by epa (subscriber, #39769) [Link] (4 responses)

there are a LOT of packages out there that are extremely useful under some conditions, but under other conditions (and frequently with default configs) open up your system
Yes... clearly the philosophy of 'let the user install standard packages' is at odds with the philosophy 'do not install a daemon unless you intend to run it'. If the user has rights to install httpd, then the default must be not to start it.

However, that does seem to be the case in modern Fedora: server packages are installed not-starting by default and you must use chkconfig(1) or some other means to enable them.

Apart from servers that start by default or suid binaries, in principle there is no package that can open up the system, since the user could always compile and run the code himself.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 11:54 UTC (Thu) by drag (guest, #31333) [Link] (3 responses)

> Yes... clearly the philosophy of 'let the user install standard packages'
> is at odds with the philosophy 'do not install a daemon unless you intend
> to run it'. If the user has rights to install httpd, then the default must
> be not to start it.

Not really.

Running updates and installing new versions of existing packages is a
critical action required to keep your system secure.

This should be as easy and convenient as possible.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 16:50 UTC (Thu) by cry_regarder (subscriber, #50545) [Link] (2 responses)

Right...update packages. Great. So when I am working online and have my 75 tabs open and do a user switch, I want that user to decide that NOW is the time to update the packages.

Firefox can't deal with being updated (it WILL crash or start behaving erratically forcing a restart). How about when PackageKit suggests that the system be rebooted? Will that user have the permissions to reboot my system?

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 16:52 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

User has permission to reboot the system in practically any distribution. PackageKit wouldn't have a problem with that.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 16:58 UTC (Thu) by cry_regarder (subscriber, #50545) [Link]

Sorry. It's not the permission to reboot. The power plug gives them that. It is the dialogue box that pops up telling/suggesting them to reboot.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 7:11 UTC (Thu) by ajf (guest, #10844) [Link] (1 responses)

Remember vrms, that silly little tool in Debian that nags you when you install non-free software packages? Maybe we need a version that nags you about packages with "kit" in their names.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 18:05 UTC (Thu) by nix (subscriber, #2304) [Link]

Not *all* of them. I can't see anything particularly wrong with RealtimeKit (other than its use of dbus with its horrible XML configuration file format, but at least admins rarely need to edit that), and DeviceKit-*'s quiet passing-on of udev events is a hell of a lot less vile than HAL with its disgusting media polling and automatic unejection of CDs you want to take out of the drive and ridiculous quirks files in a single-purpose language and God only knows what else.

The other Kits, yes, I could easily dump the lot of them off a cliff.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 9:45 UTC (Thu) by lkundrak (subscriber, #43452) [Link] (3 responses)

To those who complain: I'm just wondering, how many of you have potentially malicious local users?

And those who do, is there anyone who was, until now, using completely default installations without locking down anything (such as ability to shut down or suspend the system when a single local user, removing ability to automount media, etc.)?

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 16:46 UTC (Thu) by cry_regarder (subscriber, #50545) [Link] (2 responses)

I'm not worried about malicious users. I'm worried about household guests and family members.

If this switch is on, you can't leave your media (mythtv for example) computer alone with a guest even for 5 minutes! How suckitude is that?

Hence, if you ever have guests in your house and you might want to go to the bathroom while they are there (say using a guest account to surf the web), you must disable this feature. Since the vast majority (73.2%) of home users fall into this category, the majority of users should disable this feature. However we know that the majority of users (97.32%) never disable any default feature until they've been reamed.

Fun.

The really annoying thing is that the fedora devel list is clogged up by pages upon pages upon pages of this thread.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 17:09 UTC (Thu) by lkundrak (subscriber, #43452) [Link] (1 responses)

> I'm not worried about malicious users. I'm worried about household guests and family members.

Are you well aware that with physical access they're able to do anything anyway? In most setups family members can. When it comes to guests, the right tool for you is xguest -- you'll get a locked-down desktop for guests with no extra configuration at all.

For the rest of setups you can still change the policy; point is that defaults are sane for most setups.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 20:48 UTC (Thu) by jgarzik (guest, #8364) [Link]

Are you well aware of decades of Unix history?

Doing malicious or stupid things with physical machine access typically requires a modicum of effort, and often leaves obvious evidence behind.

With F12, all you need is a mouse click. The bar is substantially lowered.

Isn't this the case in Fedora 11 too?

Posted Nov 19, 2009 10:12 UTC (Thu) by grantingram (guest, #18390) [Link] (4 responses)

This seems to be the default in Fedora 11 as well.

Adding software using the menus (System -> Administration -> Add/Remove Software) doesn't require a root password, or in fact any sort of password.

I must admit the first time I saw this I thought it was kind of neat...

Isn't this the case in Fedora 11 too?

Posted Nov 19, 2009 10:57 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

In Fedora 11, it is not the default. It just allows you to permanently store that authorization when you enter the password for the first time. Revoke it via polkit-gnome-authorization

Isn't this the case in Fedora 11 too?

Posted Nov 19, 2009 13:57 UTC (Thu) by stickster (guest, #40146) [Link] (2 responses)

I wonder how many people are only finding about this change now because (1) they are often squarely in the single-user ws/laptop case, and (2) in practice, they've taken advantage of the "remember this authorization" function and therefore expect no further prompts.

Isn't this the case in Fedora 11 too?

Posted Nov 19, 2009 18:12 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

People are only finding out about this change now because this 'feature' only kicks in for signed repositories, and rawhide wasn't signed because people were worried about the security implications of automatic signing.

Isn't this the case in Fedora 11 too?

Posted Nov 19, 2009 18:25 UTC (Thu) by jspaleta (subscriber, #50639) [Link]

That's a fair point and adequately explains why this was noticed now and not when it was introduced in the codebase.

-jef

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 11:44 UTC (Thu) by russell (guest, #10458) [Link]

WTF!!! Who is making the decisions here? Apparently not the users. Oh wait... User are the people who are running Ubuntu.

People's reaction to this is just stupid.

Posted Nov 19, 2009 12:24 UTC (Thu) by drag (guest, #31333) [Link] (34 responses)

This thing is starting to piss me off. People's kneejerk reactions are just so hilariously misplaced here and on slashdot it's just irritating. Could people possibly think about this for 12 whole seconds before posting?

Sure it would be desirable to have a 'admin' password authentication mechanism that will use a password separate from root or the user account's password to prevent 'dinner guests' type problem. But that is the only thing wrong.

And that is taken care of properly by having guest accounts. letting random people log into your system as you will expose you to much larger problems then just them installing packages. Plus people with physical access do not need root exploits.. all they need is a bootable USB drive and your completely fucked.

Lets see what horrific mechanisms people currently use for installing and adding packages:

EXTREMELY INSECURE: 1. Invoking gtksu or gtksudo to run a GUI (like synamptic) as root, but inside a user's account

STILL INSECURE: 2. Invoking su or sudo from the command line to log into root or otherwise having root privileged applications running under a user's account

MUCH BETTER: 3. User's Application sends request to privileged system daemon to perform administrative action on their behalf.

BEST: 4. Require the user to hit ctrl-alt-f2 and log in as root.



Currently the way you have to do things in, say, Ubuntu (gtksudo) or Debian (terminal -> su) is ACTUALLY WORSE from a security perspective then Fedora 12's defaults.

Why is this not a horrible idea? (you may ask)

---- Using gtksudo is about the worst thing you could possibly do. Your handing massive amounts of controls over to your user account to do a mundane everyday and _required_ action. Keeping your system up to date is critical to keeping your system secure. Making it as easy and safe as possible to do this is a huge WIN.

Ignoring the fact that typical desktop users are required to install/update packages to keep their system secure may make it seem that this move is a bad one, but that is not the reality of this situation.

---- Local users don't need local root exploit, they don't need your user password, or your user's password or any password at all. Local users have physical access to your machine and thus they can trivially override any practical security mechanism you may have on your computer.

They can easily and quickly do things like boot up your system with a live CD or USB. They can pull the cover off your PC and plug your hard drive into a USB adapter. They can do all sorts of damage like that. Sure you can perform many steps to increase the physical security of your systems... but these steps are extra things that you have to do that are not supported in any default configuration of any desktop Linux system that has come before Fedora 12. Anyways if your having guest users you should have them use guest accounts, otherwise you have much bigger problems then them installing a http smtp server that they can't activate.

---- Installing and updating software is a mundane and every day event in the life of a typical desktop. If your in a corporate network this is undesirable, but if your running a corporate network then your a fucking moron if you do not have the ability to set network-wide controls for your users.... which combined with a configuration engine and/or network directory system is exactly what policykit is designed to give you.

This is a massive improvement over trying to establish fine grain controls over sudo... once you give users some ability to run code as root under their user account then breaking out is much easier. Using policykit/packagekit/etc you can configure your system to allow users to request privileged actions, but not have access to root account.

---- Requiring local user password for the packagekit mechanism is pure security theater. Your already proven who you are by being able to log in in the first place. It may feel safer, but it's not really going to protect you at all in any real or fundamental manner.

Having a separate 'admin' password from user password or root password is probably desirable in some situations..

People's reaction to this is just stupid.

Posted Nov 19, 2009 12:49 UTC (Thu) by Tet (subscriber, #5433) [Link] (5 responses)

Local users have physical access to your machine and thus they can trivially override any practical security mechanism you may have on your computer

Sure, they can override them, but it's not always trivial. On my machines, for example, they'd need to either get past the BIOS password to change the boot order, or physically open the machine up and change the boot disk. Both of which are possible, but not exactly trivial. It's all about the height of the bar. You seem to be claiming that because local access gives you an attack vector, it's fine to drop any additional security that might have been in place. That doesn't make sense to me. A determined attacker will always get in. But it's still worth protecting against the opportunist (and the ignorant).

Anyways if your having guest users you should have them use guest accounts

Guest accounts that are now capable of installing software without root access? I'm not sure what your point is here.

People's reaction to this is just stupid.

Posted Nov 19, 2009 13:27 UTC (Thu) by drag (guest, #31333) [Link]

Well guest accounts should not be allowed to have privileged actions.

This is easily configurable, but should be the defaults.

A 'guest account' is one that has no privileges and changes are wiped from
the system as soon as they log out.

People's reaction to this is just stupid.

Posted Nov 19, 2009 13:30 UTC (Thu) by drag (guest, #31333) [Link] (3 responses)

"""Sure, they can override them, but it's not always trivial. On my
machines, for example, they'd need to either get past the BIOS password to
change the boot order, or physically open the machine up and change the
boot disk. Both of which are possible, but not exactly trivial."""

It's a hell of a lot f-ing more trivial to do that then using package kit
to install a service or application that runs as root and is locally
exploitable.

"""You seem to be claiming that because local access gives you an attack
vector, it's fine to drop any additional security that might have been in
place. That doesn't make sense to me."""

That would not make sense if that was what I was saying, but it is not what
I am saying.

People's reaction to this is just stupid.

Posted Nov 19, 2009 20:53 UTC (Thu) by kilpatds (subscriber, #29339) [Link] (2 responses)

drag wrote:
It's a hell of a lot f-ing more trivial to do that then using package kit to install a service or application that runs as root and is locally exploitable.

Really? It takes less time to reboot my laptop and crack the HD password (full disk encryption) that it does to install a new package and break it?

Perhaps the disk encryption people should fix that...

People's reaction to this is just stupid.

Posted Nov 19, 2009 23:02 UTC (Thu) by drag (guest, #31333) [Link] (1 responses)

What distro ships with encrypted drives as the default?

What computer ships with a bios password as a default?

If you take steps to secure your stuff then that does not enter into this
discussion really. People are pissed off about the default configuration and
that is what I am talking about.

A configuration, btw, that is trivially easy to change.

People's reaction to this is just stupid.

Posted Nov 20, 2009 1:10 UTC (Fri) by kilpatds (subscriber, #29339) [Link]

drag wrote:
What distro ships with encrypted drives as the default?

FC11. At least it was so easy to do during the install it might as well have. So, I needed to know darn little to set that up. Certainly less than I need to know to turn this off.

People's reaction to this is just stupid.

Posted Nov 19, 2009 13:00 UTC (Thu) by hppnq (guest, #14462) [Link] (9 responses)

The local users discussed here are the completely random "people" who you should assume are roaming around on your system, and who can now trigger something that previously required root privileges.

Yes, this is then only one of many bad things, and not even the worst thing, that can happen to you. That's no reason to allow everyone and his dog to install software on your system.

Yes, there are many things wrong with the superuser security model. But clearly the solution is not to bypass this model. At least not until you have solved the problem that package management might actually require root privileges (reboot, device configuration, etc.) and you have solved the rather obvious security problem of running software that may not have been installed by you or someone you trust.

People's reaction to this is just stupid.

Posted Nov 19, 2009 13:40 UTC (Thu) by drag (guest, #31333) [Link] (8 responses)

"""The local users discussed here are the completely random "people" who you should assume are roaming around on your system, and who can now trigger something that previously required root privileges."""

If you leave your system unlocked and let random strangers have physical access to it then you have bigger issues then packagekit.

"""Yes, this is then only one of many bad things, and not even the worst thing, that can happen to you. That's no reason to allow everyone and his dog to install software on your system."""

Only people that are logged in locally have this ability.

And it's easily configurable.

"""Yes, there are many things wrong with the superuser security model. But clearly the solution is not to bypass this model."""

Yes it is. Giving users the ability to run code with root privileges under their account is clearly undesirable and any system that allows you to avoid this is desirable.

"""At least not until you have solved the problem that package management might actually require root privileges (reboot, device configuration, etc.)"""

The goal of all of this is to make a Desktop-oriented operating system were normal user activity can be carried out in a safe and secure manner in a user-friendly manner.

Device configuration on Fedora is carried out without user intervention as much as is possible.

Rebooting can be done by a local account without invoking sudo or su and is configurable.

I don't know what 'etc' is going to cover, but I bet that Fedora also has that taken care of.

Updating and installing software is a everyday mundane event. Especially when it comes to performing system updates it's very very desirable to have this happen with as little barriers as possible. Having insecure older versions of software running on a Linux desktop when more secure newer versions are available is a serious threat to the security of the average user's system.

""" and you have solved the rather obvious security problem of running software that may not have been installed by you or someone you trust.'""

If you let unknown or untrusted people log in with your credientials on your system and/or let them have full physical and unmonitored access (all of which is necessary in Fedora 12 to install software without your knowledge) to your systems you have much bigger issues then worrying about somebody installing software that may run as root with a local root exploit.

People's reaction to this is just stupid.

Posted Nov 19, 2009 14:09 UTC (Thu) by ledow (guest, #11753) [Link] (7 responses)

"If you leave your system unlocked and let random strangers have physical access to it then you have bigger issues then packagekit."

Schools. Colleges. Universities. Cybercafes. Businesses. Yes, even home users with kids.

Local users may not have physical access to *anything* except for the keyboard and the screen, but they are still users and still have to be allowed to *touch* the computer, even if you need to keep it locked down. You can prevent them accessing the hard drive directly, or the external ports, but you can't stop them typing on a keyboard... otherwise 99% of the world's computers are damn useless.

And this "feature" gives all of them the ability to install crap. If nothing else, that's a DoS because they could just install *every* signed bit of crap in the world.

"And it's easily configurable."

And on by default. And next-to-nobody knew about it. I don't give a damn what the option is, if there's even a *REMOTE* chance it would be something I object to, I don't want it on by default without some massive announcement.

"Giving users the ability to run code with root privileges under their account is clearly undesirable and any system that allows you to avoid this is desirable."

Again, technically "nice", practically, a nightmare. And it's the default nature that's the problem, not the feature. Home user or not, it's a silly idea to allow execution of *anything* (even signed code, which will inevitably have a flaw found in it at some point... look at any videogame console "hack") as anything other than the user that executed it, especially if it's done automatically without requiring an admin password. Windows won't let you do that (at least not by design), MacOS won't let you do that, why should Fedora be any different?

"The goal of all of this is to make a Desktop-oriented operating system were normal user activity can be carried out in a safe and secure manner in a user-friendly manner."

Yep. And even MS Windows says "This installer needs to be run as an administrator" most of the time. "runas" is your friend as a Windows admin installing software for users. There's reasons for that, signed code or not.

"Updating and installing software is a everyday mundane event."

So let's not trivialise it by making people think it is somehow "special" and has to be done automatically all the time for you because you're too stupid to type in an admin password when serious changes are made. Hell... just "memorising" the admin password on the basis of an option box the first time it's needed is more "secure" than doing this silently. And, in fact, updating and installing software is, was and always has been something more than "mundane" in terms of security.

"Especially when it comes to performing system updates it's very very desirable to have this happen with as little barriers as possible."

Agreed. But even Windows (usually) refuses to let you do stupid things with updates without asking for the admin password first, or until you log in as an admin.

"Having insecure older versions of software running on a Linux desktop when more secure newer versions are available is a serious threat to the security of the average user's system."

Totally agreed. But that's no different for any other operating system. And still Windows whinges if I try to install an MSI as a non-admin user when that MSI has to do *anything* remotely fancy.

People's reaction to this is just stupid.

Posted Nov 19, 2009 14:31 UTC (Thu) by drag (guest, #31333) [Link] (6 responses)

"""Schools. Colleges. Universities. Cybercafes. Businesses. Yes, even home users with kids."""

If you let any desktop OS be used by anonymous people directly using the default configuration your a idiot. I don't care what OS your using.

This causes problems on any system, including older versions of Fedora. Debian, Ubuntu or any thing like that. Nothing with Fedora 12's packagekit default policy changes this fact.

"""Local users may not have physical access to *anything* except for the keyboard and the screen, but they are still users and still have to be allowed to *touch* the computer, even if you need to keep it locked down. You can prevent them accessing the hard drive directly, or the external ports, but you can't stop them typing on a keyboard... otherwise 99% of the world's computers are damn useless."""

Yes 'locked down'. Like 'kiosk mode', right? As in 'not default configuration'.

I am never, ever, going to take any OS and let people use it in public without taking steps to lock it down against them. This sort of thing is extremely difficult to get right in pretty much every OS.

And anyways in systems like Ubuntu (and Fedora, I believe) the default is to let people have unfettered access to root account if they just supply them the user's password. This Fedora 12 packagekit policy change is still a MASSIVE improvement over the status quo. The only people that got this right before was Debian and that was because sudo was not configured by default, but they still screw it up by requiring the use of 'su' to do mundane desktop activities.

"""And this "feature" gives all of them the ability to install crap. If nothing else, that's a DoS because they could just install *every* signed bit of crap in the world."""

They can DOS the system a hundred different ways if they have physical access, even through just a keyboard. Anyways, what is stopping them from downloading and running any piece of code on the planet and executing it from their local account?

NOTHING.

And whats more they have the ability to download and execute any program for any purpose and you have no way of knowing if it's safe or violates the security of your user account or anything like that. With packagekit you at least know that it's a signed binary.

""" "And it's easily configurable." And on by default. And next-to-nobody knew about it. I don't give a damn what the option is, if there's even a *REMOTE* chance it would be something I object to, I don't want it on by default without some massive announcement. """

Yes they should of advertised it. This was a big mistake to let this go out without a announcement. Dumb mistake.

They should of advertised it as a feature during beta, at the very least.

What I think Fedora should do now is introduce a new 'admin' password that is different and separate from your root password and your user password. This will address most of the issues people like you have brought up and still keep most of the positive benefits.

Keep in mind some facts here:
THE NUMBER ONE PROBLEM is insecure passwords in Linux desktops. People will likely make more secure passwords if they don't have to use them all the time. If you require them to use their password for all mundane events then they will very quickly ignore security notifications and all security considerations. Either they will default to using weak passwords or they will not carry out regular system updates.

Making it as easy as possible to use secure passwords and perform system updates is PRIORITY #1. If this causes problems in other areas then this is a bad side effect, but still desirable.

People's reaction to this is just stupid.

Posted Nov 19, 2009 14:50 UTC (Thu) by drag (guest, #31333) [Link] (2 responses)

Yes... Now that I think about it you should have a admin 'role' or group
that a user must belong to in order to have the default set of mundane
desktop administrative tasks.

Things like 'mount removable media', 'reboot', 'update software' and a few
other things.

Then let the initial account created during installation belong to this
role. Then users that get added later it should be a manual task to add
these 'mundane privileges' through adding them through a role.

Then the first time that a user performs a mundane privilege then it should
prompt them to if they want to make a 'desktop admin' password or not.

Something like that.

admin role/group

Posted Nov 19, 2009 18:13 UTC (Thu) by rfunk (subscriber, #4054) [Link] (1 responses)

Minus the last paragraph, you just discovered Ubuntu's model. Which is
derived from the older "wheel" model someone else mentioned.

admin role/group

Posted Nov 19, 2009 19:41 UTC (Thu) by drag (guest, #31333) [Link]

Ubuntu's model is to give unfettered access to root if you are able to supply the user's password. Which is exactly the sort of thing I want distros to avoid completely.

It's acceptable in a single user environment, which is typical, but it's completely counter productive for most other environments. You should not be required to have root access to perform mundane and routine actions.

People's reaction to this is just stupid.

Posted Nov 19, 2009 20:49 UTC (Thu) by sjm (guest, #62085) [Link] (2 responses)

"And anyways in systems like Ubuntu (and Fedora, I believe) the default is to let people have unfettered access to root account if they just supply them the user's password."

I think in Ubuntu this is true only of the first user created (automatically added to sudo file), but not true for other users.

People's reaction to this is just stupid.

Posted Nov 20, 2009 0:39 UTC (Fri) by drag (guest, #31333) [Link]

Yeah. I now think that automatically giving all local users the ability to
install signed packages is probably a bad idea.

It should only be on automatically for the first user created during
installation and then be off by default for users created after that.

People's reaction to this is just stupid.

Posted Nov 20, 2009 17:51 UTC (Fri) by ariveira (guest, #57833) [Link]

First user is added to admin group; that admin group is the
one that has access granted by sudoers.

People's reaction to this is just stupid.

Posted Nov 19, 2009 14:56 UTC (Thu) by lkundrak (subscriber, #43452) [Link]

Very well written, drag. Thank you!

People's reaction to this is just stupid.

Posted Nov 19, 2009 16:14 UTC (Thu) by bfields (subscriber, #19510) [Link] (12 responses)

"Local users have physical access to your machine and thus they can trivially override any practical security mechanism you may have on your computer."

Not to disagree with the gist of your comment, but: aren't you imagining the wrong threat here?

Malicious local users are rarer than users that can be tricked into subverting the security of the system unintentionally; a more likely threat is from a web page or email message that claims to give users something they want (a game, a faster computer, whatever), if they follow certain instructions.

I suspect that trick is more likely to be successful if it consists of a few commands the user and cut-and-paste, than if it requires them to (for example) boot from a custom boot disk.

People's reaction to this is just stupid.

Posted Nov 19, 2009 17:15 UTC (Thu) by drag (guest, #31333) [Link] (11 responses)

""" Malicious local users are rarer than users that can be tricked into subverting the security of the system unintentionally; a more likely threat is from a web page or email message that claims to give users something they want (a game, a faster computer, whatever), if they follow certain instructions."""

This policy change only allows them to install signed packages from Fedora's repositories. It won't allow them to download a random rpm package or anything like that and allow them to install it. They would have to gain root privileges in order to do that even with Fedora 12's policy change.

(on a side note: they can install and execute any program on any system without root privileges as long as they install it to their home directory regardless of anything to do with anything. So this is something that Linux will have to improve on..)

So for your hack to work the attacker would have to trick Fedora into signing and adding their malicious software to their repository first, then trick the user to installing it through packagekit. This is certainly within the realm of possibility, but it's already a real threat prior to F12 and for other distros.

Regardless of the mechanism your using to allow users to install software (sudo, su, etc) they will know how to do it if they know how to use their desktop, right? After all installing software is a normal event. So a attacker using social engineering to run a script using 'sudo' or adding a password to a rpm is not really a sufficient barrier from social engineering being effective.

Whats worse is that if you condition the user to continuously give up their user or root password for lots and lots of different reasons then they will quickly assume that this is the normal state of affairs and simply ignore the security implications of giving out the password in the future, and be conditioned to using shitty passwords since long passwords are a huge PITA. See what happens with Window's UAC when it prompts passwords for every little thing, or the type of things that people tell other people to do in Ubuntu's forums. Once it becomes a normal sight then it loses it's effectiveness.

People's reaction to this is just stupid.

Posted Nov 19, 2009 18:21 UTC (Thu) by nix (subscriber, #2304) [Link] (6 responses)

The attack vector is obvious.

A local root hole is found in an obscure piece of software packaged by Fedora (perhaps one that, in violation of Fedora policy, runs a daemon on installations; perhaps one with a nasty bug in its installation scripts). The package is obscure, so fixing it takes a relatively low priority. This could be *any* such package: the only real constraint is that it should be obscure enough that most Fedora systems don't have it installed (and there are thousands of such packages). If the package is obscure, it's likely that it doesn't get audited much, so blackhats may very well know of holes in such packages that whitehats don't: so the window here may be very wide indeed. (In current Fedora, this is pretty unimportant, as the package is rarely installed so few people are vulnerable.)

An arbitrary code execution vulnerability is found in Firefox or one of the libraries it uses. These often take a while to fix because FF is a monstrous pig and because of the Mozilla trademark policy requiring signoff (IIRC Fedora has Firefox, not a renamed package).

Now an attacker can exploit the latter vulnerability (probably served via an ad server's rotation on a totally innocent webpage) and then use the former to get root with high probability, probably almost undetectably.

Not good.

(Note: I'm not any sort of security specialist. If *I* can generate this scenario with a few seconds' thought, actual malicious attackers surely can.)

People's reaction to this is just stupid.

Posted Nov 19, 2009 20:03 UTC (Thu) by drag (guest, #31333) [Link] (5 responses)

If a attacker gains access to your local account then they can execute arbitrary code in your user's account and end up doing pretty much whatever then wnt. So, yes, if they can (for example) inject a command in your bashrc script that will command packagekit to install a package. Then if they find a vulnerable package that installs and automatically launches a vulnerable service that runs as root then the attacker could use that to gain root access.

Yes, that is certainly a possibility.

However.... Here is another potential attack.

Imagine your attacking a typical Linux desktop user that has sudo configured to do things like mounting drives or configuring the network or updating their software.

Your trying to attack a system like that and you've managed to gain access to their account through something like a vulnerability in the flash plugin. All you have to do is just stick a job into the user's account to run 'if sudo ls > /dev/null; then sudo ~/.run_rootkit;done' every few seconds or so.

I'd say that over a period of a day or two the user would of certainly done 'sudo ifconfig' or 'sudo apt-get update' or some such thing. Thus giving the attacker unlimited access to the root account.

Of course attackers would probably just go for the most generic attack and install a keylogger or something.

----------------------

Like I said before having a 'admin' password separate from root and the user password is probably a good idea. Maybe not, I don't know. It would certainly address most concerns coming from most people.

-----------------

I think that the current #1 threat to Linux systems is users setting up OpenSSH access with weak passwords and attackers guessing those passwords through brute force. Think about that in conjunction with 'sudo'. :)

People's reaction to this is just stupid.

Posted Nov 19, 2009 21:17 UTC (Thu) by nix (subscriber, #2304) [Link] (4 responses)

Your assumption that the ability to run 'sudo yum update' implies the
ability to run 'sudo ls' or 'sudo sh' is incorrect. (Just because Ubuntu
sets it up that way doesn't mean it's the only way, or even a particularly
good one.)

At least sudo can be configured to ask you for a password (at intervals or
every time), and as it's setuid it's relatively hard for an attacker
running as the user to spy on the user's keystrokes as he types it in. So
elevation to the user does not necessarily mean you can get to root that
way.

In any case, the existence of one security hole isn't a reason to allow
another one to continue to exist!

People's reaction to this is just stupid.

Posted Nov 19, 2009 23:17 UTC (Thu) by drag (guest, #31333) [Link] (3 responses)

""" Your assumption that the ability to run 'sudo yum update' implies the ability to run 'sudo ls' or 'sudo sh' is incorrect. (Just because Ubuntu sets it up that way doesn't mean it's the only way, or even a particularly good one.) """

My assumption is based on the reality of what is a seems to be a acceptable default configuration for distros. The 'status quo', so to say. If you can lock down sudo then I can change whatever I want with package kit and it is impossible to make a good comparison.

""" At least sudo can be configured to ask you for a password (at intervals or every time), and as it's setuid it's relatively hard for an attacker running as the user to spy on the user's keystrokes as he types it in. So elevation to the user does not necessarily mean you can get to root that way."""

Yes.

The usual default configuration is to allow sudo access by prompting for a password. This is what I am talking about. And it allows you to re-run sudo without a password for a period of time. My example exploit depends on this behavior. If you run sudo from one console then that gives unlimited root access to any sudo command without prompting for a password for a period of time for every instance of that user's account.

Of course this is configurable, but remember the dispute is about default configurations. I am not sure how it is with Fedora, but people don't seem to have a problem with Ubuntu and I think it's the same.

""" In any case, the existence of one security hole isn't a reason to allow another one to continue to exist! """

Sure... But you have to realize that the use of things like packagekit and policykit is to eliminate the need for things like sudo for typical desktop activities.

I am of the opinion that a desktop that does not require running root code under a user's account as a part of normal everyday activities is superior to one that does. I am looking forward to the day that a user is able to perform every common function on the desktop without requiring root access or running root code under their account and this is a big step in that direction. No distro should ship with sudo enabled for anything!

Sudo and su should be reserved for administrators and experts. Expecting normal users to be able to use these things safely is asking too much. And using gtksudo (and similar things) to run GUI applications entirely as root under your account is a huge security hole in itself. Probably the thing should ask for a admin password or something like that, but I think that asking for a user's password is security theater and asking for a root password is just a plain bad idea.

People's reaction to this is just stupid.

Posted Nov 20, 2009 2:29 UTC (Fri) by khc (guest, #45209) [Link] (2 responses)

If you run sudo from one console then that gives unlimited root access to any sudo command without prompting for a password for a period of time for every instance of that user's account.
That is not true (at least by default) in ubuntu. If I give sudo password in one terminal, running it again *in another terminal* requires me to enter the password again.

People's reaction to this is just stupid.

Posted Nov 20, 2009 2:36 UTC (Fri) by foom (subscriber, #14868) [Link] (1 responses)

That does nothing for security, however. There is no security barrier between two terminals running
as the same UID: The second terminal is just a ptrace() away from making the first terminal run
sudo for it...

People's reaction to this is just stupid.

Posted Nov 20, 2009 12:26 UTC (Fri) by hppnq (guest, #14462) [Link]

You can't ptrace() sudo, and you can't run sudo with suid if the parent is traced. It is not that stupid. ;-)

(Obviously, if you have a terminal you have other ways to snoop passwords.)

People's reaction to this is just stupid.

Posted Nov 19, 2009 18:45 UTC (Thu) by dlang (guest, #313) [Link] (3 responses)

but something they install in their home directory will not be setuid root

something that the package manager installs may be.

People's reaction to this is just stupid.

Posted Nov 19, 2009 23:40 UTC (Thu) by drag (guest, #31333) [Link] (2 responses)

Sure.

Having setuid root binaries is a security problem themselves, period, and
that sort of thing should eliminated...

People's reaction to this is just stupid.

Posted Nov 20, 2009 0:44 UTC (Fri) by gmaxwell (guest, #30048) [Link] (1 responses)

At least suid is trivially auditable (find!) and there is decades of established practices, policy, and procedures in dealing with it. I can walk into any library or bookstore and find books on securing systems that cover the subject of SUID binaries and that knowledge and experience is generally portable, not just to all GNU/Linux distributions but across unixes in general.

Eliminating SUID by replacing it with controls buried in a windows-registry like database isn't necessarily an improvement.

People's reaction to this is just stupid.

Posted Nov 20, 2009 1:21 UTC (Fri) by drag (guest, #31333) [Link]

Eliminating SUID by replacing it with controls buried in a windows- registry like database isn't necessarily an improvement.

Not always, of course. But I think in the case of policykit and the other *kits it is.

This is simply because it should be unnecessary to perform normal desktop operations without resorting to running privileged code under a user's account. These things eliminate that for common cases.

I don't think that sudo/su should be eliminated for everything. It should be reserved as a administrative tool and users should only be required to be prompted for the root password or run root code under their account in special cases. I think that in the cases of installing/updating software is such a mundane and everyday event that invoking root password or running code as root is diminishing the security of the typical desktop scenario when a alternative exists.

Now for managed desktops then that sort of activity should be forbidden, which is easy enough to accomplish through packagekit/policykit.

(also I don't consider storing policy as XML files in directories to be anything like what the negative things the windows registry does...)

I do think that having this default spread to _all_ user accounts by default is a bad idea, though.

People's reaction to this is just stupid.

Posted Nov 19, 2009 19:16 UTC (Thu) by clugstj (subscriber, #4020) [Link] (1 responses)

"This thing is starting to piss me off."

Well, that could be because you are WRONG and too proud to admit it (even to yourself). Take some time to cool down and then read the posts here and in the Fedora bug and entertain the possibility that everyone who disagrees with you is not necessarily an idiot.

People's reaction to this is just stupid.

Posted Nov 19, 2009 23:53 UTC (Thu) by drag (guest, #31333) [Link]

Of course I could be wrong. I am frequently wrong about a lot of things. Nothing surprises me.

But the discussion is irritating because most of the initial responses were blatantly incorrect in a large amounts of their assumptions and made discussing the thing almost impossible. They didn't even take time to think. It violated some unthinking beliefs in what makes a secure system and they objected it simply by appearance only.

Also I know that just because you have a minority opinion with you does not make you wrong. Also there is no reason to believe that if a group of people are very loud in their opinions and objections that they are in the majority. There is no such thing as a democracy or popularity/loudness scale in the reality of right or wrong.

People's reaction to this is just stupid.

Posted Nov 20, 2009 10:49 UTC (Fri) by russell (guest, #10458) [Link]

Installing software is not mundane. Do you really want user upgrading the system. Possibly breaking the system because it may require kernel packages not available in fedora, or because the repo is currently broken ( don't say it doesn't happen, because it does ).

Your assertion about local access is totally wrong. You obviously need to secure your computer better.

If users need to install software. They can do it in there own home directory. That's more secure than 1, 2, 3 or 4.

People's reaction to this is just stupid.

Posted Nov 21, 2009 17:49 UTC (Sat) by k8to (guest, #15413) [Link]

There are some OK points in your rant, but explicit su - is more secure than the other options.

su -
run packaging commands
exit

Or really, what i do:

I open a terminal for root activities, color it red, and creat a completely new login as root. I use that terminal for packaging, or editing config files, and not much more.

The programs that get exposed via my methods:

- the shell
- the editor
- the packaging tools

PolicyKit might be able to cut out the editor, but it still has to use those programs and several additional ones. The system is more complex and harder to inspect. My environment is not polluted from the user's.

Really this is the most simple, and the most secure, and the most easily inspected method. My reaction to PolicyKit is "I hope i can prevent it from being used on my distribution."

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 13:53 UTC (Thu) by nye (guest, #51576) [Link] (1 responses)

I can't really understand objections to this policy.

This would only seem to be a problem in the case that a user is logged in with the ability to elevate their privileges to install a package, then they go away leaving it unlocked, and another person starts using it and installs some software.

It's unlikely that you've let a malicious user physically access your unlocked machine while you're logged in but not present, and in this case they could already do far more damage than installing some software - they have unfettered access to your $HOME after all.

I just can't think of any circumstances in which this could cause any problems.

I am making the following assumptions:

1) This policy only allows users to install packages without a password, in cases where they previously would have been able to *with* one. This is my most important assumption and might be the point where opinions differ; if I'm wrong about this one then that would change things.

2) A corporate deployment of Fedora won't allow users to install packages, even *with* their password, so there is no change.

Less important ones:

3) The majority of home computers are used by only one user (Microsoft found that over 70% of computers are only ever used by one person)

4) The *overwhelming* majority of home computers are used by one or an small number of users, and anyone with access to it will already be able to install packages by entering their password.

5) A guest account could be created which requires no password, and has very limited permissions (for people who want to let somebody else use their computer).

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 14:33 UTC (Thu) by kragil (guest, #34373) [Link]

I agree.

Ways to appease the very vocal minority.

Don't allow it for guests or remote users. (I guess that is the default.)
Only allow updates to packages. (Only the admin can install NEW software)

Most importantly: Make a Fedora server spin with sane server defaults so all the server admins with too much time at their hands will shut up :P

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 19:55 UTC (Thu) by abadidea (guest, #62082) [Link] (1 responses)

I'm a CS student in charge of managing the workstations around here, some of which are Linux. And my reaction to this is: "WAT."

Just because something is in an official repository doesn't mean I'm totally okay with it being on my computer and my network. A clever student could manually compile some of those programs I specifically chose not to install, but if they need to be setuid (which a lot of the iffy ones do) then that won't help them much. If someone can be trusted to install software at a whim, then why aren't they already a sudoer?

Now it happens that I don't run Fedora on anything, but I *know* that a lot of admins of Linux workstations out there are not even gonna realize this is enabled till it bites them somehow. It totally goes against the principle of least surprise, as it's not expected behavior at all.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 23:38 UTC (Thu) by drag (guest, #31333) [Link]

"""I'm a CS student in charge of managing the workstations around here, some of which are Linux. And my reaction to this is: "WAT.""""

Policykit is designed specifically to help administrators add or deny privileges to users based on easy-to-port configurations. Right now you'll need a configuration engine to manage it properly, but in the future they will be configurable via LDAP.

Think about the ability to apply 'group policies' in a way that is similar to what Active Directory users are able to do.

""" Now it happens that I don't run Fedora on anything, but I *know* that a lot of admins of Linux workstations out there are not even gonna realize this is enabled till it bites them somehow. It totally goes against the principle of least surprise, as it's not expected behavior at all."""

Yes. Fedora screwed up by not making this change more apparent. That is a bad move. But this is the point of using fedora... users and developers are given the freedom to play around. This is part of what makes Fedora desirable.. people are able to get access to cutting-edge Linux features and functionality. This is just one of a hundreds unmentioned changes that happenned between F11 and F12.

If you want predictability stick to something that is designed to be predictable.. (Debian Stable, Ubuntu LTS, CentOS, Redhat, etc).

Without a doubt this feature WILL be in other distros after it's been given a bit more time to have the issues ironed out and people have become comfortable with the concepts and policies being introduced.

Signed packages alone is not sufficient to protect the system from malicious software...

Posted Nov 20, 2009 1:27 UTC (Fri) by drag (guest, #31333) [Link] (1 responses)

I was reading through the comments on the mailing list and I realize now
that having signed packages is insufficient to guarantee the security of
the packages.

The reason is because if a person uses a malicious mirror they can retain
outdated copies of the packages that contain known vulnerabilities. Then
they can trick administrators into using these outdated mirrors through a
MITM attack or DNS poisoning or something like that.

However this is a vulnerability for any method of updating your system.
This affects, but is not reserved to PackageKit... yum/apt-get/wget
pipes/etc are affected.

So the solution is that the server you download the lists of packages from
must be authenticated and communication must be secure through mechanisms
like TLS. Now the packages themselves don't have to be downloaded via a
TLS/SSL secured server because they are signed.. but the package management
system must always have the updated lists provided through a more secure
mechanism.

Signed packages alone is not sufficient to protect the system from malicious software...

Posted Nov 20, 2009 14:55 UTC (Fri) by skvidal (guest, #3094) [Link]

metalinks are the default mechanism for getting the mirrorlist from fedora. They are accessed over https and urlgrabber in f12 checks certificates properly.
So, yes, that's done.

Fedora 12 lets unprivileged users install packages

Posted Nov 20, 2009 4:11 UTC (Fri) by quaid (guest, #26101) [Link]

There has been an update to this discussion:

https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01445.html

I encourage you to read the whole email, it's not long and has good summary/explanation of the situation.

For the impatient ...

"Executive summary
=================

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

Letting unprivileged users benefit from packages

Posted Nov 21, 2009 19:14 UTC (Sat) by pboddie (guest, #50784) [Link]

I don't have time to read the discussion (largely rehashed from prior discussions, I imagine) about the advantages and disadvantages of letting any user request system-wide package installation, but there are various working environments where letting users benefit from distribution packages would be a hugely beneficial thing. Of course, such packages would be installed as owned by the user, in the user's own area, and wouldn't be able to interact with privileged resources.

A while back, I took debootstrap, fakeroot and fakechroot and made a small project which combined them to let me install user-local packages on Debian/Ubuntu systems. While this was likely to be incomplete and possibly flawed (and unnecessary on my own personal machine), it would be hugely beneficial for me at work where I'm between a rock (being an unprivileged user on a Red Hat system) and a hard place (having to endure the usual institution-wide policies about software installation). Maybe I can use febootstrap and find a Fedora repository which is compatible with RHEL.

Not letting unprivileged users benefit from the system packaging infrastructure just drives people to niche package distribution systems like CPAN, Ruby Gems and Python's easy_install. Although these systems have their adherents, they are poor replacements for the infrastructure that may already be in place, but which is inaccessible to the disempowered end-user.

I'd like to see end-user package management done the right way: harnessing RPMs and Debian packages under the user's own privileges in order to automate (or bypass, really) the grunt-work of having to {.configure, make, make install} a bunch of libraries just to have access to a benign application that isn't likely to get installed by an administrator.


Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds