Fedora 12 lets unprivileged users install packages
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.
Posted Nov 18, 2009 23:53 UTC (Wed)
by midg3t (guest, #30998)
[Link] (12 responses)
1. Find package with recent, unpatched privilege escalation vulnerability.
Posted Nov 19, 2009 0:30 UTC (Thu)
by sladen (guest, #27402)
[Link] (10 responses)
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.
Posted Nov 19, 2009 0:55 UTC (Thu)
by etrusco (guest, #4227)
[Link]
Posted Nov 19, 2009 0:55 UTC (Thu)
by jspaleta (subscriber, #50639)
[Link] (8 responses)
-jef
Posted Nov 19, 2009 1:23 UTC (Thu)
by sbergman27 (guest, #10767)
[Link] (7 responses)
Does it understand the concept of "local dinner parties" vs "remote dinner parties"? "Local
Has anyone looked into how well this kind of thinking worked for Windows?
Posted Nov 19, 2009 7:29 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (6 responses)
Posted Nov 19, 2009 7:46 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (5 responses)
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?
Posted Nov 19, 2009 9:06 UTC (Thu)
by mjthayer (guest, #39183)
[Link] (4 responses)
Posted Nov 19, 2009 15:31 UTC (Thu)
by geisler (guest, #44380)
[Link]
Posted Nov 19, 2009 17:24 UTC (Thu)
by sir99 (guest, #3286)
[Link] (2 responses)
Posted Nov 19, 2009 19:35 UTC (Thu)
by drag (guest, #31333)
[Link]
Posted Nov 19, 2009 20:39 UTC (Thu)
by SEJeff (guest, #51588)
[Link]
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.
Posted Nov 19, 2009 0:46 UTC (Thu)
by dskoll (subscriber, #1630)
[Link] (9 responses)
Looks like the Fedora crowd now have their very own WTF, so I don't feel so bad.
Posted Nov 19, 2009 0:59 UTC (Thu)
by airlied (subscriber, #9104)
[Link] (8 responses)
Posted Nov 19, 2009 12:00 UTC (Thu)
by dskoll (subscriber, #1630)
[Link] (7 responses)
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.
Posted Nov 19, 2009 14:34 UTC (Thu)
by nevyn (guest, #33129)
[Link] (6 responses)
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.
Posted Nov 19, 2009 15:54 UTC (Thu)
by dskoll (subscriber, #1630)
[Link] (5 responses)
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.
Posted Nov 19, 2009 19:55 UTC (Thu)
by dskoll (subscriber, #1630)
[Link] (3 responses)
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.
Posted Nov 19, 2009 20:36 UTC (Thu)
by mebrown (subscriber, #7960)
[Link] (2 responses)
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.
Posted Nov 19, 2009 20:45 UTC (Thu)
by jgarzik (guest, #8364)
[Link]
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?
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.
Posted Nov 19, 2009 0:53 UTC (Thu)
by elanthis (guest, #6227)
[Link] (8 responses)
Posted Nov 19, 2009 1:03 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (6 responses)
Posted Nov 19, 2009 2:24 UTC (Thu)
by djcapelis (guest, #53964)
[Link] (5 responses)
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.
Posted Nov 19, 2009 2:39 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (4 responses)
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.
Posted Nov 19, 2009 13:27 UTC (Thu)
by fuhchee (guest, #40059)
[Link] (3 responses)
Right, it's just an *additional* way of elevating privileges.
Posted Nov 19, 2009 18:11 UTC (Thu)
by drag (guest, #31333)
[Link] (2 responses)
Posted Nov 19, 2009 18:48 UTC (Thu)
by foom (subscriber, #14868)
[Link] (1 responses)
Posted Nov 19, 2009 19:38 UTC (Thu)
by drag (guest, #31333)
[Link]
And you are right that it's a poor match with what we have to deal with
That and it's just one of dozens of examples.
Posted Nov 19, 2009 1:06 UTC (Thu)
by ofeeley (guest, #36105)
[Link]
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.
Posted Nov 19, 2009 1:09 UTC (Thu)
by cmccabe (guest, #60281)
[Link] (3 responses)
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.
Posted Nov 19, 2009 1:23 UTC (Thu)
by hadess (subscriber, #24252)
[Link] (2 responses)
Posted Nov 19, 2009 3:41 UTC (Thu)
by jgarzik (guest, #8364)
[Link] (1 responses)
Posted Nov 19, 2009 6:49 UTC (Thu)
by bojan (subscriber, #14302)
[Link]
PS. Speaking as a long time user of Fedora.
Posted Nov 19, 2009 1:43 UTC (Thu)
by gmaxwell (guest, #30048)
[Link] (4 responses)
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.
Posted Nov 19, 2009 1:46 UTC (Thu)
by nix (subscriber, #2304)
[Link] (3 responses)
Horribly underdocumented mishmash I agree with. I have no idea how to use
Posted Nov 19, 2009 1:51 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
pklocalauthority(8) polkit(8) polkitd(8) pkaction(1), pkcheck(1), pkexec(1)
It could be better but it is not empty either.
Posted Nov 19, 2009 1:56 UTC (Thu)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Nov 19, 2009 4:15 UTC (Thu)
by halfline (guest, #31920)
[Link]
Posted Nov 19, 2009 1:54 UTC (Thu)
by tonyblackwell (guest, #43641)
[Link] (4 responses)
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.
Posted Nov 19, 2009 2:45 UTC (Thu)
by linuxjacques (subscriber, #45768)
[Link] (1 responses)
It seems that the best solution for now is 'yum erase PackageKit'
Posted Nov 19, 2009 12:34 UTC (Thu)
by drag (guest, #31333)
[Link]
"Gee these guys may have a point, let me try to figure out why they think
Because they actually do have a point and they actually are not wrong about
Posted Nov 19, 2009 11:52 UTC (Thu)
by Tet (guest, #5433)
[Link]
Posted Nov 19, 2009 23:54 UTC (Thu)
by sbakker (subscriber, #58443)
[Link]
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 :-)
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: 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....
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.
Posted Nov 19, 2009 6:44 UTC (Thu)
by dlang (guest, #313)
[Link] (5 responses)
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
Posted Nov 19, 2009 9:48 UTC (Thu)
by epa (subscriber, #39769)
[Link] (4 responses)
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.
Posted Nov 19, 2009 11:54 UTC (Thu)
by drag (guest, #31333)
[Link] (3 responses)
Not really.
Running updates and installing new versions of existing packages is a
This should be as easy and convenient as possible.
Posted Nov 19, 2009 16:50 UTC (Thu)
by cry_regarder (subscriber, #50545)
[Link] (2 responses)
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?
Posted Nov 19, 2009 16:52 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
Posted Nov 19, 2009 16:58 UTC (Thu)
by cry_regarder (subscriber, #50545)
[Link]
Posted Nov 19, 2009 7:11 UTC (Thu)
by ajf (guest, #10844)
[Link] (1 responses)
Posted Nov 19, 2009 18:05 UTC (Thu)
by nix (subscriber, #2304)
[Link]
The other Kits, yes, I could easily dump the lot of them off a cliff.
Posted Nov 19, 2009 9:45 UTC (Thu)
by lkundrak (subscriber, #43452)
[Link] (3 responses)
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.)?
Posted Nov 19, 2009 16:46 UTC (Thu)
by cry_regarder (subscriber, #50545)
[Link] (2 responses)
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.
Posted Nov 19, 2009 17:09 UTC (Thu)
by lkundrak (subscriber, #43452)
[Link] (1 responses)
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.
Posted Nov 19, 2009 20:48 UTC (Thu)
by jgarzik (guest, #8364)
[Link]
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.
Posted Nov 19, 2009 10:12 UTC (Thu)
by grantingram (guest, #18390)
[Link] (4 responses)
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...
Posted Nov 19, 2009 10:57 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (3 responses)
Posted Nov 19, 2009 13:57 UTC (Thu)
by stickster (guest, #40146)
[Link] (2 responses)
Posted Nov 19, 2009 18:12 UTC (Thu)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Nov 19, 2009 18:25 UTC (Thu)
by jspaleta (subscriber, #50639)
[Link]
-jef
Posted Nov 19, 2009 11:44 UTC (Thu)
by russell (guest, #10458)
[Link]
Posted Nov 19, 2009 12:24 UTC (Thu)
by drag (guest, #31333)
[Link] (34 responses)
Posted Nov 19, 2009 12:49 UTC (Thu)
by Tet (guest, #5433)
[Link] (5 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 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.
Posted Nov 19, 2009 13:27 UTC (Thu)
by drag (guest, #31333)
[Link]
This is easily configurable, but should be the defaults.
A 'guest account' is one that has no privileges and changes are wiped from
Posted Nov 19, 2009 13:30 UTC (Thu)
by drag (guest, #31333)
[Link] (3 responses)
It's a hell of a lot f-ing more trivial to do that then using package kit
"""You seem to be claiming that because local access gives you an attack
That would not make sense if that was what I was saying, but it is not what
Posted Nov 19, 2009 20:53 UTC (Thu)
by kilpatds (subscriber, #29339)
[Link] (2 responses)
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...
Posted Nov 19, 2009 23:02 UTC (Thu)
by drag (guest, #31333)
[Link] (1 responses)
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
A configuration, btw, that is trivially easy to change.
Posted Nov 20, 2009 1:10 UTC (Fri)
by kilpatds (subscriber, #29339)
[Link]
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.
Posted Nov 19, 2009 13:00 UTC (Thu)
by hppnq (guest, #14462)
[Link] (9 responses)
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.
Posted Nov 19, 2009 13:40 UTC (Thu)
by drag (guest, #31333)
[Link] (8 responses)
Posted Nov 19, 2009 14:09 UTC (Thu)
by ledow (guest, #11753)
[Link] (7 responses)
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.
Posted Nov 19, 2009 14:31 UTC (Thu)
by drag (guest, #31333)
[Link] (6 responses)
Posted Nov 19, 2009 14:50 UTC (Thu)
by drag (guest, #31333)
[Link] (2 responses)
Things like 'mount removable media', 'reboot', 'update software' and a few
Then let the initial account created during installation belong to this
Then the first time that a user performs a mundane privilege then it should
Something like that.
Posted Nov 19, 2009 18:13 UTC (Thu)
by rfunk (subscriber, #4054)
[Link] (1 responses)
Posted Nov 19, 2009 19:41 UTC (Thu)
by drag (guest, #31333)
[Link]
Posted Nov 19, 2009 20:49 UTC (Thu)
by sjm (guest, #62085)
[Link] (2 responses)
I think in Ubuntu this is true only of the first user created (automatically added to sudo file), but not true for other users.
Posted Nov 20, 2009 0:39 UTC (Fri)
by drag (guest, #31333)
[Link]
It should only be on automatically for the first user created during
Posted Nov 20, 2009 17:51 UTC (Fri)
by ariveira (guest, #57833)
[Link]
Posted Nov 19, 2009 14:56 UTC (Thu)
by lkundrak (subscriber, #43452)
[Link]
Posted Nov 19, 2009 16:14 UTC (Thu)
by bfields (subscriber, #19510)
[Link] (12 responses)
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.
Posted Nov 19, 2009 17:15 UTC (Thu)
by drag (guest, #31333)
[Link] (11 responses)
Posted Nov 19, 2009 18:21 UTC (Thu)
by nix (subscriber, #2304)
[Link] (6 responses)
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.)
Posted Nov 19, 2009 20:03 UTC (Thu)
by drag (guest, #31333)
[Link] (5 responses)
Posted Nov 19, 2009 21:17 UTC (Thu)
by nix (subscriber, #2304)
[Link] (4 responses)
At least sudo can be configured to ask you for a password (at intervals or
In any case, the existence of one security hole isn't a reason to allow
Posted Nov 19, 2009 23:17 UTC (Thu)
by drag (guest, #31333)
[Link] (3 responses)
Posted Nov 20, 2009 2:29 UTC (Fri)
by khc (guest, #45209)
[Link] (2 responses)
Posted Nov 20, 2009 2:36 UTC (Fri)
by foom (subscriber, #14868)
[Link] (1 responses)
Posted Nov 20, 2009 12:26 UTC (Fri)
by hppnq (guest, #14462)
[Link]
(Obviously, if you have a terminal you have other ways to snoop passwords.)
Posted Nov 19, 2009 18:45 UTC (Thu)
by dlang (guest, #313)
[Link] (3 responses)
something that the package manager installs may be.
Posted Nov 19, 2009 23:40 UTC (Thu)
by drag (guest, #31333)
[Link] (2 responses)
Having setuid root binaries is a security problem themselves, period, and
Posted Nov 20, 2009 0:44 UTC (Fri)
by gmaxwell (guest, #30048)
[Link] (1 responses)
Eliminating SUID by replacing it with controls buried in a windows-registry like database isn't necessarily an improvement.
Posted Nov 20, 2009 1:21 UTC (Fri)
by drag (guest, #31333)
[Link]
Posted Nov 19, 2009 19:16 UTC (Thu)
by clugstj (subscriber, #4020)
[Link] (1 responses)
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.
Posted Nov 19, 2009 23:53 UTC (Thu)
by drag (guest, #31333)
[Link]
Posted Nov 20, 2009 10:49 UTC (Fri)
by russell (guest, #10458)
[Link]
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.
Posted Nov 21, 2009 17:49 UTC (Sat)
by k8to (guest, #15413)
[Link]
su -
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
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."
Posted Nov 19, 2009 13:53 UTC (Thu)
by nye (subscriber, #51576)
[Link] (1 responses)
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).
Posted Nov 19, 2009 14:33 UTC (Thu)
by kragil (guest, #34373)
[Link]
Ways to appease the very vocal minority.
Don't allow it for guests or remote users. (I guess that is the default.)
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
Posted Nov 19, 2009 19:55 UTC (Thu)
by abadidea (guest, #62082)
[Link] (1 responses)
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.
Posted Nov 19, 2009 23:38 UTC (Thu)
by drag (guest, #31333)
[Link]
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
The reason is because if a person uses a malicious mirror they can retain
However this is a vulnerability for any method of updating your system.
So the solution is that the server you download the lists of packages from
Posted Nov 20, 2009 14:55 UTC (Fri)
by skvidal (guest, #3094)
[Link]
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 ...Fedora 12 lets unprivileged users install packages
2. Install package.
3. Exploit privilege escalation vulnerability.
4. Profit!
Haystack surrounding a needle.
Haystack surrounding a needle.
Haystack surrounding a needle.
Haystack surrounding a needle.
lets be clear... remote users aren't privledged by default. PolicyKit understands the concept of
console user versus remote.
"""
children" vs "remote children"?
Haystack surrounding a needle.
Haystack surrounding a needle.
Haystack surrounding a needle.
Haystack surrounding a needle.
Haystack surrounding a needle.
Haystack surrounding a needle.
Haystack surrounding a needle.
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
> 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?
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
or fancy mechanics to deal with basic security we had solved years ago.
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
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.
Fedora 12 lets unprivileged users install packages
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
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
you can configure the system ahead of time.
today.
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
of your rant for yourself.
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
Not a new direction
Not a new direction
PK: configuring it appears to require bashing largely-undocumented XML
into policy files.
Not a new direction
Not a new direction
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
Fedora 12 lets unprivileged users install packages
"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"
Fedora 12 lets unprivileged users install packages
"are you people all insane?"
Fedora 12 lets unprivileged users install packages
they way they do even if they might be wrong ultimately"
it.
Yep, that's the real problem here. Not that it was a bad decision (which it plainly was), but that:
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
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 [...]
Fedora and target audience
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.
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
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.
Fedora 12 lets unprivileged users install 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.
critical action required to keep your system secure.
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
Isn't this the case in Fedora 11 too?
Isn't this the case in Fedora 11 too?
Isn't this the case in Fedora 11 too?
Isn't this the case in Fedora 11 too?
Isn't this the case in Fedora 11 too?
Fedora 12 lets unprivileged users install packages
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?
People's reaction to this is just stupid.
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..
Local users have physical access to your machine and thus they can trivially override any practical security mechanism you may have on your computer
People's reaction to this is just stupid.
People's reaction to this is just stupid.
the system as soon as they log out.
People's reaction to this is just stupid.
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."""
to install a service or application that runs as root and is locally
exploitable.
vector, it's fine to drop any additional security that might have been in
place. That doesn't make sense to me."""
I am saying.
drag wrote:People's reaction to this is just stupid.
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.
People's reaction to this is just stupid.
discussion really. People are pissed off about the default configuration and
that is what I am talking about.
drag wrote:People's reaction to this is just stupid.
What distro ships with encrypted drives as the default?
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.
People's reaction to this is just stupid.
"""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."""
People's reaction to this is just stupid.
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.
"""Schools. Colleges. Universities. Cybercafes. Businesses. Yes, even
home
users with kids."""
People's reaction to this is just stupid.
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.
that a user must belong to in order to have the default set of mundane
desktop administrative tasks.
other things.
role. Then users that get added later it should be a manual task to add
these 'mundane privileges' through adding them through a role.
prompt them to if they want to make a 'desktop admin' password or not.
admin role/group
derived from the older "wheel" model someone else mentioned.
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.
admin role/group
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.
People's reaction to this is just stupid.
install signed packages is probably a bad idea.
installation and then be off by default for users created after that.
People's reaction to this is just stupid.
one that has access granted by sudoers.
People's reaction to this is just stupid.
People's reaction to this is just stupid.
"""
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."""
People's reaction to this is just stupid.
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.
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.
People's reaction to this is just stupid.
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.
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.)
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.
another one to continue to exist!
"""
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.)
"""
People's reaction to this is just stupid.
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.
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.
as the same UID: The second terminal is just a ptrace() away from making the first terminal run
sudo for it...
You can't ptrace() sudo, and you can't run sudo with suid if the parent is traced. It is not that stupid. ;-)
People's reaction to this is just stupid.
People's reaction to this is just stupid.
People's reaction to this is just stupid.
that sort of thing should eliminated...
People's reaction to this is just stupid.
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.
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.
Of course I could be wrong. I am frequently wrong about a lot of things.
Nothing surprises me.
People's reaction to this is just stupid.
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.
People's reaction to this is just stupid.
run packaging commands
exit
- the editor
- the packaging tools
Fedora 12 lets unprivileged users install packages
Fedora 12 lets unprivileged users install packages
Only allow updates to packages. (Only the admin can install NEW software)
Fedora 12 lets unprivileged users install packages
"""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.""""
Fedora 12 lets unprivileged users install packages
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...
that having signed packages is insufficient to guarantee the security of
the packages.
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.
This affects, but is not reserved to PackageKit... yum/apt-get/wget
pipes/etc are affected.
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...
So, yes, that's done.
Fedora 12 lets unprivileged users install packages
"Executive summary
=================
We'll make an update to the F12 PackageKit, so that the root password is required to install packages."
Posted Nov 21, 2009 19:14 UTC (Sat)
by pboddie (guest, #50784)
[Link]
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.
Letting unprivileged users benefit from packages