LWN: Comments on "Fedora 12 and unprivileged package installation"

Fedora 12 and unprivileged package installation

fuhchee — Fri, 15 Jul 2011 17:20:44 +0000

"Since the release, and all of the publicity and complaints, the maintainers of PackageKit have decided to remove the feature."

It came back a few months later.
https://bugzilla.redhat.com/show_bug.cgi?id=568074

Fedora 12 and unprivileged package installation

vonbrand — Thu, 10 Dec 2009 14:07:53 +0000

Plan9, were art thou...

Fedora 12 and unprivileged package installation

nix — Sun, 06 Dec 2009 01:52:25 +0000

I think that's half-right. You want the /var/usr/$USER idea, sure, but it
is bind-mounted by pam_mount into a per-user private mount, maybe /usr/usr
(ew, maybe somewhere else) and *that* is what is referenced in PATHs.

(Most of the rest of your post is talking about problems that GNU stow and
graft and other similar systems have long considered and solved. Suffice
to say that systems built from symlink farms are quite practical. Hell,
systems built from symlink farms *at runtime*, so users can have per-user
and even per-session package selection are practical, although the farm
construction might take a second or two. I've implemented a couple of
systems like that myself...)

Fedora 12 and unprivileged package installation

kasperd — Sat, 05 Dec 2009 23:23:43 +0000

If you want to go that way, I think the rpms should be installed in a directory named something similar to /var/usr/$USER.

The entire hierarchy under /var/usr should be writable only by some system user, installing packages should be done by a program that is suid to that user.

If two users installs the same package, then the files can be hardlinked into both users' directories. The program to perform the install can also manage some sort of quotas.

Obviously it should not be possible to install any suid or sgid executables or any device inodes. Running the install as a non-root user guarantees part of that.

There is a problem with how programs find their files. They would either need to be modified to use the USER environment variable, or you would need a symlink somewhere that magically points to /var/usr/$USER and then use paths through that. (There are already symlinks in /proc that magically changes depending on which process access them, so adding another magical symlink doesn't seem too far fetched). Of course it may still be problematic that an rpm can either be installed in the normal location by root or a different location by somebody else. Could be worked around by building two versions of each rpm.

The only reason I suggest a directory name depending on the user is, that one user installing a program shouldn't cause that program to show up in another user's path. Each user would have /var/usr/$USER/bin in their path, and only see programs they want to see there.

If some files are accessed by a path that is determined at compile time, maybe those should be put into a common directory instead. That would avoid most of the user dependent path requirements. Say user1 installs app with a binary named app and a library named libapp.so.1, then each file of the two files could be hardlinked in two locations.

/var/usr/user1/bin/app
/var/usr/user1/lib/libapp.so.1
/var/usr/common/bin/app
/var/usr/common/lib/libapp.so.1

And user1 would access /var/usr/user1/bin/app from the path which would then use /var/usr/common/lib/libapp.so.1. The common directories shouldn't be in any path, but if you want to specify the absolute path to for example an executable you would use the one in /var/usr/common/bin/app.

I may have missed some details that would need to be figured out, but I'm pretty sure it can be made to work within the normal unix security model, if anybody wants to do the work.

Fedora 12 and unprivileged package installation

nix — Thu, 03 Dec 2009 23:26:03 +0000

Filesystem namespaces can be used for this, but allowing users to modify a
private copy of / has security implications: many many programs assume
that things in /etc aren't modifiable except by privileged users (trivial
example: /etc/passwd, /etc/shadow).

Fedora 12 and unprivileged package installation

simlo — Tue, 01 Dec 2009 13:38:25 +0000

Isn't the main problem that RPMs can't be installed in the users home directory instead of /? Then any user could install any RPM he wants to without being root. Ofcourse, it wouldn't make sense for system level programs, but for normal applications it would be really nice. It would require a lot of changes to each RPM, but I would say it would be worth it instead of opening for security hacks like these.

Otherwise, / should be uid dependent and therefore each user could see his own version of the installed software base without affecting the other users or the system. I think I read somewhere, that Plan9 can do just this. Can namespaces in Linux be used for this?

tone of the article

louie — Tue, 01 Dec 2009 01:23:52 +0000

That was quite a biased article... Sorry, but how can I be sure you presented the case fair when you have clear bias?

I'd just like to ditto this. I have subscribed to LWN for years because it makes an attempt to really understand all sides of an issue before taking an editorial stance, and so I trust Jon's judgment. This article shows no such nuance or balance, which is a shame and not what I expect from LWN.

Secure keyboard input

mjg59 — Thu, 26 Nov 2009 17:40:10 +0000

So the attacker makes sure that your xterm is thunked with an LD_PRELOADed library that reports a successful grab without actually performing one. Xterm continues along its way and your password still gets grabbed. Xterm's grabs are intended to secure against hostile *X* applications that may be running on machines out of your control. That's simply not the common threat model any more, and instead it just results in people thinking that they're secure when they're not.

(Heck. The attacker could ignore X altogether and just thunk read and write in xterm and read everything going over the pty. You'd end up with a secure channel between the server and the xterm, which would win you absolutely nothing overall)

Secure keyboard input

jmorris42 — Wed, 25 Nov 2009 23:59:25 +0000

Kids today..... :)

Fire up an xterm (a real one) and observe the first option on the menu if you press CTRL-F1 is Secure Keyboard. It is intended to be used for exactly the sort of thing you mention. X had thought of security and built it in long before NT 3.1 'invented' it, the GNOME/KDE kids simply forgot about that sort of thing along with most of the other good parts of X.

Seems to be a pattern with modern graphical free software development to repeat all of Microsoft's security mistakes and for the same reason. The mad rush to bring about 'the Year of Linux on the Desktop' is producing the exact same marketing based security policies that we have laughed our butts off over when Microsoft originally made em. But apparently we learned nothing.

Fedora 12 and unprivileged package installation

Tara_Li — Wed, 25 Nov 2009 23:01:24 +0000

You have to admit, the normal situation makes life easier in a way:

You end up with three kinds of people:

1) The people who have their own computer, with root access, and can install anything they like.

2) The people who's computer is managed by someone else, and they can install nothing.

3) A few people who can think well enough to install binary tarballs, or if the appropriate toolchain is installed on their computer, they can actually compile from source code.

It certainly simplifies things for the package maintainers - they don't have to bother looking to see if root is installing the package, and therefore everyone can use the program, or if a user is installing the package, in which case the files should be stored in *THEIR* home directory, and the program is not available to everyone else.

Of course, how many admins actually want to give their users access to something like a compiler! That's just asking for them to be able to use their computers in ways the admin doesn't want them to.

Fedora 12 and unprivileged package installation

miguelzinho — Wed, 25 Nov 2009 20:38:18 +0000

That's what I always say: Fedora is just a playground for Red Hat. Community participation my ass: all the core packages are controlled by Red Hat employees dictates what goes in or not; servers are hosted at Red Hat; that's new to me, they can make private comments, WTF?

Fedora 12 and unprivileged package installation

Baylink — Wed, 25 Nov 2009 20:37:47 +0000

Well, if one lives in one's parents' basement, then people walking up to the machine is probably a lesser concern, yes. :-)

Fedora 12 and unprivileged package installation

Baylink — Wed, 25 Nov 2009 20:34:39 +0000

My personal opinion is that if Hughes "doesn't particularly care how Unix has always worked", then he's in the wrong job.

If that's how Fedora runs, then I'm glad I'm a SuSE patriot. I feel vindicated in that choice.

*My* first distribution was Tandy Xenix 1.3 and SCO Xenix 2.2.1. How long has Hughes been doing this?

Secure keyboard input

cmccabe — Mon, 23 Nov 2009 19:31:17 +0000

> Which is why Linux desktops really need a secure attention sequence
> such as the Ctrl-Alt-Delete used by Windows (and before that, VMS).
> No application may trap that keystroke, and it leads you to a screen
> with only the password entry dialogue and (as far as I know) no
> communication with other parts of the desktop.

That's a very good point. It's important to have a secure login path. This is an especially important issue in a shared computer lab, where people can log into any machine they like.

It would be nice if gnome or KDE could be configured to request an "uninterceptable" keystroke combination before allowing you to log in through gdm or xdm. I don't know enough about X input handling to know how feasible this would be.

Secure keyboard input

madscientist — Mon, 23 Nov 2009 18:35:41 +0000

Any really sensitive file in the user's home directory should be protected by account permissions so that non-root users wouldn't be able to modify, or even read, them. In addition, a number of distros already have the ability to encrpyt some or all of the user's home directory, so that casual observers can't read the files. I think the previous poster has an excellent point, though: if you don't have a foolproof way of getting back to a login prompt, you can't say much about any sort of password-based security, including encrpyted home directories.

Fedora 12 and unprivileged package installation

clugstj — Mon, 23 Nov 2009 17:01:32 +0000

Is anyone using RBAC in Solaris? Just because it is "in production" doesn't mean that it is any good.

Secure keyboard input

drag — Mon, 23 Nov 2009 15:58:51 +0000

If Linux can figure out a way to lock down things inside of a user account then that would benefit everybody massively.

If you think about it (which you probably already understand completely, I am just talking about in a more general sense), right now all your most important and sensitive information is stored in your /home/$USERNAME directory. Especially for a single user system, which 70% of desktops apparently are, then getting root is not necessary at all for a attacker to have the most damage to that user.

Root is only necessary for the attacker to go unnoticed. If they want to establish a rootkit or run some sort of secret network service then they'll need root. If they just want to steel your credit card information, gain access to your online accounts, or anything like that then root is unnecessary.

Fedora 12 and unprivileged package installation

luya — Mon, 23 Nov 2009 08:58:55 +0000

Lets not forget PolicyKit is part of Freedesktop.org. It is somewhat similar Solaris RBAC in term of concept.

Fedora 12 and unprivileged package installation

hppnq — Mon, 23 Nov 2009 07:28:53 +0000

We have had grsecurity for years. Quite popular, but developed outside of the kernel.

Fedora 12 and unprivileged package installation

salimma — Mon, 23 Nov 2009 01:53:45 +0000

sudo is still available -- the first step I did after installing a Fedora/Red Hat system is to add myself to wheel and edit sudoers. There are cases where using yum from the command line is much faster (and customizable) than using PackageKit (and relying on PolicyKit to manage permissions)

Fedora 12 and unprivileged package installation

pspinler — Mon, 23 Nov 2009 01:13:35 +0000

Instead of inventing something completely different, could some existing framework like Opensolaris / Solaris 10's RBAC (http://www.softpanorama.org/Solaris/Security/solaris_rbac...) be used?

It'd have the advantage of already being in production several years, having a open source reference implementation in Opensolaris (although it'd have to be reimplemented due to license incompatibility) already having an LDAP schema for central administration, and already having a set of people knowledgeable about it.

-- Pat

Fedora 12 and unprivileged package installation

dark — Sun, 22 Nov 2009 22:39:32 +0000

When the city council announces plans to demolish the local parks and playgrounds in order to construct bike sheds, the people who jump in with opinions are not just bikeshedding.

Secure keyboard input

epa — Sun, 22 Nov 2009 19:45:07 +0000

It's trivial to install a keylogger.

Which is why Linux desktops really need a secure attention sequence such as the Ctrl-Alt-Delete used by Windows (and before that, VMS). No application may trap that keystroke, and it leads you to a screen with only the password entry dialogue and (as far as I know) no communication with other parts of the desktop.

It's kind of embarassing that for many years Windows has had better security than Linux in this one area. The 'schoolboy attack' of locking the screen and bringing up a fake password dialogue is also trivial.

So I quite agree that conditioning users to type in their password (or, perhaps worse, the root password) all the time is a terribly bad idea. However, asking them to hit Ctrl-Alt-Delete and enter their password into a secure authentication screen will piss them off, and perhaps also condition them to ignore the boring message and just authorize the action every time, but at least it does not have the problem of keyloggers or trojan websites which pop up 'enter your password' dialogues.

Non-technical users, who (demonstrably) cannot distinguish between genuine password prompts and bogus ones from malware, can at least be told to always hit Ctrl-Alt-Del before entering their password. It may not be enough, but at least it's something.

(For remote access, a remote secure attention sequence is also possible; for example many Windows remote desktop clients have a 'send Ctrl-Alt-Del' menu option, which again cannot be intercepted by ordinary applications.)

Fedora 12 and unprivileged package installation

mattdm — Sun, 22 Nov 2009 18:30:20 +0000

We need some dismissive term for people who get over-enamored with the bike shed story and subsequently dismiss anyone who disagrees with them as bike shedding.

Fedora 12 and unprivileged package installation

nhippi — Sun, 22 Nov 2009 18:05:38 +0000

Then I can mount any file system I like on that drive with or without my admin's approval. If he believed that by plugging in a USB drive that contains important files and by formatting the volume Ext3 and setting up file system permissions he could keep me from reading or writing to certain files then he would be sorely mistaken.

If a admin believes ext3 makes files on usb stick safe the admin is not mistaken, the admin is stupid.

Then again, it is known for at least last 10 years that granting hardware access by the traditional UNIX user:group setup just doesn't correlate with reality. Observe the historic discussion with /dev/dsp permissions. previously we had two choices:

1) add a user to "audio" group.

..means the user can remotely eavesdrop local users.

2) grant user access (by temporarily adding to audio group or by chowning it to the user) to /dev/dsp when logging into console and remove the permissions when logging out

..means the user can open /dev/dsp when visiting console, and leave a daemon reading it and remotely eavesdrop local users.

same applies to floppies, usbsticks etc. Hopefully policykit etc will deal with it eventually.

Fedora 12 and unprivileged package installation

NAR — Sun, 22 Nov 2009 12:19:34 +0000

Last time I've checked it wasn't useful. By the way, why does a desktop "single-user" installation has a root password at all? The recent IPhone worm showed how "useful" it is to have...

Fedora 12 and unprivileged package installation

kragil — Sun, 22 Nov 2009 01:03:49 +0000

Why only install and not update? I think just updates would have been sane.

BTW can this convenience feature be enabled in Ubuntu?

Fedora 12 and unprivileged package installation

luya — Sat, 21 Nov 2009 19:57:45 +0000

Like using a tool without consulting a manual guide.

Fedora 12 and unprivileged package installation

MarkWilliamson — Sat, 21 Nov 2009 19:50:23 +0000

To be fair, dismissing a legitimate debate as mere bike shedding was perhaps
not a very diplomatic way of phrasing things ;-)

Security policy expertise

PO8 — Sat, 21 Nov 2009 19:06:00 +0000

Wha? Nobody is asking you to have a security expert working on "every application". They're asking you to have a security expert working on the applications which control your security policy. Especially when those applications are new and present unique challenges. Any distro that can't afford that should stick with the tried-and-true UNIX security model and its implementation rather than trying to innovate in the security policy arena.

A removed feature

k8to — Sat, 21 Nov 2009 17:36:47 +0000

Yes. This is what you get when you shoot for security with lots of features.

Fedora 12 and unprivileged package installation

k8to — Sat, 21 Nov 2009 17:34:05 +0000

It's not about how hard it is to click the settings. It's about how hard it is to be sure that the settings do exactly what you expect them to do.

If you can't be sure of exactly what they're doing, then you aren't creating security, you're creating false comfort.

Fedora 12 and unprivileged package installation

amonnet — Sat, 21 Nov 2009 17:03:50 +0000

I might look old fashionned, but i really enjoy the good old UNIX way to treat theses kind of permissions.

New PolicyKit, DeviceKit, IdontKnownWhatKit, with their balkanized permission configuration file, have me wanted to bang my head on a rock.

I really miss my old /etc/group, /etc/sudoers and /etc/security/group.conf when presented with a dialog box telling me i have no right to do something (and absolutely no understanding what configuration file i should change).

Fedora 12 and unprivileged package installation

AdamW — Sat, 21 Nov 2009 16:34:59 +0000

Sort of a fair point, but for most distributions it's not practical to have a security expert working on every application which could possibly have security implications (...er, just about all of 'em). Hence, as has already been discussed, the improvement needed here is just to ensure that Fedora's processes ensure there's more oversight of potentially sensitive changes to any component. Seth Vidal is already working on a proposal for this.

Nasty coverup

man_ls — Sat, 21 Nov 2009 13:55:43 +0000

But it was wrong to have it as the default for all local users and it was wrong for them to do this without being more vocal about it.

Judging just from the article, the biggest mistake was not to silently make the change, but to disregard the opinions of their own users. And it doesn't look like there was a clear use case for installing software as non-root, just that they didn't want to admit their mistake. Not very professional, and something that on my own distribution would make me wary of all design decisions I am not aware of.

Fedora 12 and unprivileged package installation

ballombe — Sat, 21 Nov 2009 12:38:27 +0000

I like to note that selinux is sometimes configured to forbid users to install shared library in their home dir.

> brw-rw---- 1 root floppy 8, 16 Nov 20 17:49 /dev/sdb

It is an udev configuration problem: as configured it tries to guess what
the device is to add it to the relevant group and sometimes it makes wrong guess (e.g. a scanner was marked as a floppy).

> But after that any new user defaults to no group membership except their own, so it's not too bad. Just as long as I don't get UID 1000 on Debian then any removable media is safe from me. :)

It should be noted that the extra groups are only added to the user
created during the installation process. The assumption is whoever install the machine is the admin. Further more since you are also in plugdev, you can mount filesystems anyway.

Fedora 12 and unprivileged package installation

tzafrir — Sat, 21 Nov 2009 12:16:47 +0000

Which brings up another such "exceptional" condition: adding an extra repository.

Is the typical Fedora "desktop" installation useful enough without adding such an extra repository?

Fedora 12 and unprivileged package installation

hppnq — Sat, 21 Nov 2009 12:11:33 +0000

In general, I would say it is all of them.

Fedora 12 and unprivileged package installation

luya — Sat, 21 Nov 2009 10:28:22 +0000

Actually Policykit is not that hard the first time I used on Fedora 11. There are front-end (System->Preferences->Authorization on Gnome desktop) that allow configuration and fine-graining control unlike sudo (I have not for a long time because it is not a long term good choice).

Because that front-end is gone on Fedora 12 I have to relearn the policy setting from terminal (or using text-editor). The good thing about PolicyKit (Polkittool) is the ease of use and human readability.

Selinux has tremendously evolved. it is very easy to submit bug report so policy can be updated as soon as possible.

Packagekit is not hard at all although it does not have yumex complex functionality. However the ability to detect missing codec, fonts and the fact it is backend independent (yum, apt-deb, smart, conakry) cannot be overlooked. Because of my design field, I mostly use it for simple update and use yum for advanced function.

I think the biggest problem in this community is the fear of change and inertia for some traditional users. Let not forget Fedora is all about cutter technologies.

Fedora 12 and unprivileged package installation

NAR — Sat, 21 Nov 2009 09:57:29 +0000

Prompting people for their own passwords for normal events conditions them to use weak passwords.

I think installing software is not a normal event, but an exceptional. I install software about 2-3 times per year (after the initial OS installation, when it takes some time to get every necessary software). On the other hand as far as I understand, Fedora <12 used to ask the password only once in a session, so they had a fairly good compromise between security and usability that was broken with the upgrade...