Fedora 12 and unprivileged package installation [LWN.net]

Fedora 12 and unprivileged package installation

Posted Nov 20, 2009 23:17 UTC (Fri) by Frej (guest, #4165)
Parent article: Fedora 12 and unprivileged package installation

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

And stuff like like this is slashdot worthy:

For a distribution that went through a great deal of pain to integrate SELinux features in order to increase the security of the system, it is mind- boggling to many that this non-root install feature was added as the default

Security is a compromise.

Thus, either we have the best security in the world with no users because it's too anoying Or, we try to find the sweet spot for a certain set of users, we can't please everyone.

Example: We could require entering root password every time a new website is accessed (almost like installing a program today), but i doubt users would accept it. It's too cumbersome.

----
Another way to solve this, is for desktop users just to install the app per user (thus requiring no extra permissions). But we are stuck in designing software that manages software, which is very nice for sysadmins or others who want to sysadm their laptop ;)

to post comments

Fedora 12 and unprivileged package installation

Posted Nov 21, 2009 0:10 UTC (Sat) by drag (guest, #31333) [Link] (17 responses)

I wouldn't call it "slashdot worthy". That's just mean. He's smart and does a good job expressing his editorial opinion. :)

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. This is not _huge_ fuck-ups, but it's something that in 20-20 hindsight is something fairly obvious and they should learn from that.

But security is a very difficult thing, right?

Prompting people for their own passwords for normal events conditions them to use weak passwords. They have already proven their identity by being able to log into the system in the first place. Asking them again is just redundant. It's like forcing people to use their house key in order to access the bathroom. Prompting people for root passwords just means that they will use weak root passwords and will condition them to accept typing in root password as a normal event.

In addition to that it does not provide any real additional security. If a attacker has subverted your system or you do not trust the software your running in your home environment then additional passwords provide no real additional benefit.

It's trivial to install a keylogger. Especially with 'xrecord' extension that is built-in everybody's X server. If it was not for the fact that it is broken in newer versions of Xorg's X server I could right a 30-line python program (in addition to python-xlib) that would capture every keystroke you type in and save it to a file or send it over the network. It does not require any root rights or any privileges beyond access to your user's account. It is probably very likely that it's still quite easy for people to do keystroke loggers even with a broken Xrecord. There are a dozen different programs that are designed specifically to do that for doing automation or training or scripting or whatever. Like 'Xnee' (which uses xrecord).

And people ignore pop-ups. After I've seen the same pop up 2-3 times I will ignore it or (accidentally) ignore anything that looks almost exactly like that. It's human nature. So that is not the answer either, except when a event is rare.

"""Another way to solve this, is for desktop users just to install the app per user (thus requiring no extra permissions). But we are stuck in designing software that manages software, which is very nice for sysadmins or others who want to sysadm their laptop ;)"""

They can already do that.

I used to regularly install video games and proprietary software and similar things to my ~/Apps directory. I started doing that since I noticed that most video games (like ID Quake3) tended to use really shitty file system permissions. Fixing damage typical games and proprietary software did to my directory tree was always a pain, so I always tried to avoid giving them root access when ever possible. (I fixed this by avoiding using proprietary now whenever possible). There is even a entire ~/.local/ directory for most Linux users you can install things to that most people have never noticed.

Sure you can run 'ldconfig' and add library paths, but that's easy enough to work around with simple shell scripts that you use to launch applications.

Hell, you can run entire operating systems if you want entirely from your home directory using Qemu (or KVM if you have that configured correctly). This has some interesting security issues. For example:

My user cannot mount file systems on their own, not without using 'su' or 'sudo' to elevate privileges. They can use policykit to mount things, but whatever. Lets see what happens when I plug in a USB drive into my system:

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

Notice something interesting? Lets look at the defaults for my user:

drag@debian-router:~$ groups
drag dialout cdrom floppy audio video plugdev

Why does Debian do that? I have no freaking clue. It's not a terribly good idea. Especially since the the HAL/Devicekit stuff works so well so there should be no need for that. But they still do that, tradition I suppose.

Now I can go and edit those things, but that will likely corrupt the FS and be difficult. But if I go:

qemu -hda drive-image -hdc /dev/sdb

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. So now it's obvious that any sort of file system level restrictions in Debian is completely worthless against the default user.

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

Fedora 12 and unprivileged package installation

Posted Nov 21, 2009 0:15 UTC (Sat) by drag (guest, #31333) [Link]

... Debian is completely worthless against the default user ..

I meant to say:

.. Debian is completely worthless against the default user for removable
media ...

At least media that shows up with 'floppy' group.

Fedora 12 and unprivileged package installation

Posted Nov 21, 2009 8:10 UTC (Sat) by bojan (subscriber, #14302) [Link]

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

Excellent summary of the whole thing.

Fedora 12 and unprivileged package installation

Posted Nov 21, 2009 9:57 UTC (Sat) by NAR (subscriber, #1313) [Link] (3 responses)

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

Fedora 12 and unprivileged package installation

Posted Nov 21, 2009 12:16 UTC (Sat) by tzafrir (subscriber, #11501) [Link] (2 responses)

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

Posted Nov 22, 2009 12:19 UTC (Sun) by NAR (subscriber, #1313) [Link] (1 responses)

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

Posted Nov 25, 2009 20:37 UTC (Wed) by Baylink (guest, #755) [Link]

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

Posted Nov 21, 2009 12:38 UTC (Sat) by ballombe (subscriber, #9523) [Link]

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.

Nasty coverup

Posted Nov 21, 2009 13:55 UTC (Sat) by man_ls (guest, #15091) [Link]

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

Posted Nov 21, 2009 17:03 UTC (Sat) by amonnet (guest, #54852) [Link] (1 responses)

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

Posted Nov 23, 2009 1:53 UTC (Mon) by salimma (subscriber, #34460) [Link]

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

Posted Nov 22, 2009 18:05 UTC (Sun) by nhippi (subscriber, #34640) [Link]

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.

Secure keyboard input

Posted Nov 22, 2009 19:45 UTC (Sun) by epa (subscriber, #39769) [Link] (5 responses)

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

Secure keyboard input

Posted Nov 23, 2009 15:58 UTC (Mon) by drag (guest, #31333) [Link] (1 responses)

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.

Secure keyboard input

Posted Nov 23, 2009 18:35 UTC (Mon) by madscientist (subscriber, #16861) [Link]

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.

Secure keyboard input

Posted Nov 23, 2009 19:31 UTC (Mon) by cmccabe (guest, #60281) [Link]

> 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

Posted Nov 25, 2009 23:59 UTC (Wed) by jmorris42 (guest, #2203) [Link] (1 responses)

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.

Secure keyboard input

Posted Nov 26, 2009 17:40 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

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)

tone of the article

Posted Dec 1, 2009 1:23 UTC (Tue) by louie (guest, #3285) [Link]

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.