Fedora 12 Lets Users Install Signed Packages, Sans Root Privileges

eqisow writes "The new default policy for Fedora 12 allows local, unprivileged users to install signed packages without root access. This change apparently went mostly unnoticed until after the Fedora 12 GA release, at which point it sparked a mailing list thread that is, as of this writing, over 100 posts long."

Comments

Wow

[MyLongNickName]

Sounds like I need to upgrade to Windows 7 for some real security...

Re:Wow

[Monkeedude1212]

I'm not even sure who to ROOT for anymore.

Haha, that was so terrible, please don't mod me funny.

Re:Wow

[gbarules2999]

With all of this opt-in sudo-security breaking, Fedora could be looking into Windows of an Absolute Vector that results in gettting the Boot and being thrown in the Bin.

I, unlike you, feel no shame.

Re:Wow

[ethan0]

I'm seeing lots of comments on the security of this, but I'm not seeing how it is insecure. Users can currently install any software they want into their home directory - how is this any different? it goes into a system directory, sure, but that doesn't give the user any more privileges with regard to it.

An possible exception is if the package is setuid root, is runnable by any user, and has some exploit to get the user root. Does this happen? I can't think of what could have this, and it doesn't seem like the package manager should install such things (regardless of known exploitability - bugs do happen) Perhaps if this functionality is applied only to software that does not escalate privileges at all? I would consider that a sensible default, but don't know if that is the case here.

Re:Wow

[DavidRawling]

There are at least 2 attack vectors I think I see.

1. User installs an old version of a package with a locally exploitable privilege escalation bug.

2. User installs an app with the same name as a script or program usually used by root (or a sudoer) that is malicious, and appears earlier in the path than the normal copy of that command.

Re:Wow

[DavidRawling]

And here's a third.

3. Malicious Javascript in a web page that gets the browser to download a signed package, executes the installation, executes the local privilege escalation bug, and uses the new root privilege to download and install anything it wants to.

Re:Wow

[Antique Geekmeister]

You need the package to have a signature that is already registered. Fedora 12, like early Fedora releases, doesn't register _any_ GPG keys for RPM until after manual authentication by the user. "yum install" asks for this during software installation. Unfortunately, many sites that deal with signed packages don't protect their signatures well, and it's dificult to tell which signatures for RPM are installed or appropriate. So it's a vector, just not as bad of one as you note.

Glad to see...

[maccodemonkey]

...all those laid off Microsoft employees already found work.

Re:Glad to see...

[Anonymous Coward]

Now we just wait to see how long it takes someone to digitally sign a rootkit!

Re:It's obvious

[junglee_iitk]

Or you could install RHEL

That is what they want, apparently:
https://www.redhat.com/archives/fedora-devel-list/2009-November/msg00945.html

"Should the defaults be targeted towards home users or corporate desktop
considering the short lifecycle of Fedora and the target audience? I am
not sure there are corporate deployments but wouldn't they be heavily
customized their desktop deployments and kickstarting it anyway?"

whatcouldpossiblygowrong?

[rrohbeck]

Just hope that your appliance manufacturer has disabled this.

Re:whatcouldpossiblygowrong?

[jim_v2000]

Why would an appliance be running Fedora?

This makes sense

[Anonymous Coward]

If the content is trusted then requiring the user to get root privileges is just a security risk (key-loggers). I do hope, however, that they had to foresight to require specific permissions to allow users to install signed packages. I don't want my guest users installing every signed package and filling my HDD.

Re:This makes sense

[Anonymous Coward]

So with Microsoft it's a fail but here it's a feature? Man, my head is spinning.

Re:This makes sense

[MatanZ]

The contest might be trusted, but not wanted by the administrator of the machine.

Another way to think about it - you are now vulnerable to local root exploits not only in packages you installed, but also in packages you chose not to install.

Re:This makes sense

[Reason58]

If the content is trusted then requiring the user to get root privileges is just a security risk (key-loggers). I do hope, however, that they had to foresight to require specific permissions to allow users to install signed packages. I don't want my guest users installing every signed package and filling my HDD.

Signed doesn't mean bug-proof. Everything a user installs is just one more attack vector.

Re:This makes sense

[fluch]

No, it does NOT make sense. It creates a new security risk: If some malicious software (runing under with normal user privileges) notices that a hackable software is missing on the computer (one which has a known security vulnerability to gain root access) it can now install this package without problem and gain root access later on.

A sudo approach like done in Ubuntu is much better.

Re:This makes sense

[Anonymous Coward]

If Ubuntu extended this right to every user who was in the admin group then I would have no problem whatsoever. It's just a question of not having to provide your password. FC providing it to all users? Easy DDOS, just install lots of stuff. Or what if they install SSHD on a machine that shouldn't have SSHD running? I bet the package sets it to start in all runlevels by default, meaning that users have the ability to open up huge security holes. Imagine a user thinking "I have an old version of package X that has a security hole, but I can install it since it's signed, and therefore gain r00t!"

Terrible idea, just terrible.

Re:This makes sense

[Arimus]

No, its a fail. Any OS vendor / Linux distro which thinks this is a good idea needs whacking hard with a two-by-four till they get the message that this a fail whoever does it.

Re:This makes sense

[Draek]

So, you argue that this is a security measure to protect systems that are already compromised with keyloggers? I... see, right... *backs away slowly*

Re:This makes sense

[mweather]

Microsoft lets you install unsigned code as well. Signed code isn't nearly as big a problem, unless they're signing keyloggers and spambots. It's still a problem, but nowhere near as bad.

Re:This makes sense

[CannonballHead]

Microsoft lets you install unsigned code as well.

Without being admin/having to go through the UAC thing?

Re:This makes sense

[jim_v2000]

Guest users? That's good...everyone knows that Linux users don't have any guests.

Re:This makes sense

[natehoy]

No, there is a significant difference between "running as Admin" and "installing a signed application without requiring root (Linux's Admin) authority".

The amount of authority granted depends on how many signing authorities you have decided to trust. If you trust only a server under your own control, for example, this could be really useful within an organization to allow users to install company-authorized packages without having to run around and install everything for everyone, while still preventing average users from doing anything to the machine.

I don't agree with this change in RedHat, but it is (fortunately) a policy change and not a programming change. In other words, it's easy for any machine owner to change the policy (which can, by the way, only be done as root) and require that all software installs be done by root only (which was the old default). In my opinion, this default should be changed back, and those people who want to send signed packages out within their organizations can change the policy.

A regular RedHat user still cannot do things like reformat the hard drive, change operating system files or core system configurations, access any data but their own, etc. Similar to a "Limited" user account in Windows (but the difference is that Microsoft, by default, has traditionally made all accounts Admin, and a lot of software vendors have come to depend on that so making a Limited user is an exercise in deep frustration in Windows).

Re:This makes sense

[jmorris42]

> Another way to think about it - you are now vulnerable to local root exploits not only
> in packages you installed, but also in packages you chose not to install.

DING! You nailed it. The attack surface has been expanded to include every package in every enabled repo. Find a local root exploit in any one of them and you get the machine.

This is totally stupid. It makes the assumption that every user is an admin, which was exactly the idiocy we have, rightly, laughed at Microsoft for years over. Microsoft has been working at correcting that mistake while we have been adopting it. And it isn't just Fedora, this apparently came from upstream at PackgeKit so unless this gets nipped in the bud it will spread to everyone else.

The root of the problem is that decisions that impact security are being made by marketing people more concerned with the 'year of the Linux desktop'. And again, wasn't this exactly what we slagged Microsoft over in the past? As Linux nears readiness for mass consumption we find ourselves making exactly the same mistakes for exactly the same reasons. We are tossing decades of hard won security knowledge onto the altar of user friendliness.

We didn't learn anything. We are doomed.

Re:This makes sense

[nine-times]

If the content is trusted then requiring the user to get root privileges is just a security risk (key-loggers). I do hope, however, that they had to foresight to require specific permissions to allow users to install signed packages.

I could see having some kind of permission that can be set to allow particular users the rights to install signed packages without any additional administrative rights. That could be useful. However, I don't think it would make sense to have that right granted to non-admin users in the default case. It should be a right that the admin needs to specifically grant to users before it is allowed.

Re:This makes sense

[TooMuchToDo]

When Linux requires a root password via sudo to do everything, everyone cheers. When Windows Vista required an admin password to do the same administrative tasks, everyone complained.

Re:This makes sense

[msclrhd]

And installing random stuff is an easy way to destabalise a system.

What... I want to install kubuntu-desktop on this ubuntu-desktop machine. (Yes, I know the issue is in Fedora, but the same principle applies.)

Re:This makes sense

[Anonymous Coward]

Use your head man! If any single bug is found in any signed kernel driver anywhere ever, a piece of malware will auto-fetch the signed driver (or just come packaged with it), install the said buggy driver (no su access needed!), and promptly exploit it to gain root access for itself.
Any signed buggy driver will be a gaping security hole until it's signed status is somehow revoked - and until it is revoked, ANY program can use it to get kernel mode access. This has all the makings of an permanent security hole.

Re:This makes sense

[jim_v2000]

That's the thing. Every time you see a comparison of security in Windows and Linux, the users in Windows is always assumed to be the administrator, and you get all this FUD about how insecure Windows is. The proper comparison would be to a Windows machine where the user is logged in as a limited user. In that case, it's as secure as a Linux box.

Re:This makes sense

[jim_v2000]

It makes perfect sense and entirely appropriate for home/personal use. If you're in a corporate environment, disable the feature.

Re:This makes sense

[Arimus]

Not quite everyone... I didn't for one.

Though in a console environment typing sudo (assuming your in the sudoers file) is easier than a popup in a gui...

And vista does have one issue: run command as a normal user and there is no equiv to sudo ipconfig /flushdns - you need to know you are going to run admin commands before you open the command prompt and run it as an admin user. Which is one thing I don't like about it...

Re:This makes sense

[harlows_monkeys]

I don't think you are supposed to have guest users. One of the Fedora guys said in the thread cited in the submission, saying why that is not a problem:

This assumes the user is different from a admin, which is not true for a personal desktop

Apparently, it hasn't occurred to him that some people actually have others living in the same household who might share the computer.

Re:This makes sense

[the_womble]

The thing is that Linux does not require the root password to do everything. The commonest task that requires it is installing software.

From what I understood of the complaints about Vista, it required the root password a lot more than Linux does.

Re:This makes sense

[VGPowerlord]

That's the thing. Every time you see a comparison of security in Windows and Linux, the users in Windows is always assumed to be the administrator, and you get all this FUD about how insecure Windows is. The proper comparison would be to a Windows machine where the user is logged in as a limited user. In that case, it's as secure as a Linux box.

If you'd ever actually used Windows Vista/7 as an admin user, you'd know that you still get a UAC prompt for program installers. A different one than a limited user would get (theirs asks for an admin username and password too, iirc).

Or, for that matter, for any program that attempts to certain locations on disk (determined by Windows itself, but including the Windows directory, the Program Files directory, and the various user directories that aren't yours as I recall).

Re:This makes sense

[TooMuchToDo]

I'll admit, I'd much rather run as root than sudo all the damn time on a Linux box.

Re:This makes sense

[thue]

I wonder if they handle replay attacks?

IE, assume version 1 of a packages had a bug, which was fixed in version 2. But then an attacker manually downloads version 1 and installs it. SInce version 1 was also signed by Red Hat it will install, and you have a local root hole...

Re:This makes sense

[bheer]

Mod parent +1 insightful. I can't believe idiots are crawling out of the woodwork to defend this.

Folks, Microsoft OSes require confirmation of all software (included signed packages) since 2007. It's now 2009 and you're developing *Linux*. Please don't repeat past follies.

Re:This makes sense

[fluch]

So giving malware which runs with user privileges a possibility to automaticaly request the installation of a package with known root exploit makes sense for home/personal use?

Re:This makes sense

[jmorris42]

> I wonder if they handle replay attacks?

Under normal conditions it wouldn't work. Yum won't allow unpriviledged users to install things, those guys aren't idiots. This is a hook into the command line that triggers if you type the name of a command that isn't installed. So it would only grab the most recent version it knew of.

And anyway, when did making the command line user friendly become such a big push, I though we were supposed to consider any use of the command line a bug to be fixed by an new multi-megabyte graphical horror. :)

Of course if you can prevent the machine from downloading the updated package lists you could probably trick it.

Re:This makes sense

[tinkerghost]

I'll admit, I'd much rather run as root than sudo all the damn time on a Linux box.

sudo bash

works for Ubuntu without ever activating root login. It's what I use when I go in to edit .conf files.

Re:This makes sense

[anglophobe_0]

Wow. That was ignorant. I use sudo on my fedora box all the time. You really should look things like that up before assuming fedora doesn't have a feature. Also, if you read the bugzilla you'll see VERY clearly that it's superd00per easy to disable the default feature.

And for crying out loud, giving users access to install a package is a lot more desirable than giving them full access to do anything with sudo. Sure, you can lock sudo down pretty easily too, but honestly, do you?

Either way, if you're an admin who's worth half his salt, you'll make it exactly the way you want, and screw the defaults.

Lastly, under the defaults with selinux targeted running, along with the fact that practically no network-accessible services run as root, you'd be hard-pressed to gain root access through any of those services you mentioned.

Way to go, modding up a bunch of FUD.

Re:This makes sense

[XSpud]

The contest might be trusted, but not wanted by the administrator of the machine.

I agree - this separation is the norm in just about any corporate environment I've come across. There may be good reasons for staggering the roll-out of trusted software within an organization including: user training issues, ensuring compatibility with other software, making sure hardware is up to scratch etc.

This policy change removes the ability of admins to manage the roll-out of software to multiple users.

Re:This makes sense

[Josh04]

Only because terribly written software was used to writing all over the place all the time. Vista only requires root for the same kind of things linux does.

The only other complaint was that it showed an inordinate amount of alerts for the same thing, file copying into protected folders, which was fixed in SP1. I'd still prefer the Vista SP0 4 dialogs to what Nautilus does (i.e, tell me to get fucked.)

Re:This makes sense

[jim_v2000]

lol, I think I replied to the wrong thread.

Re:This makes sense

[digsbo]

You can install RPMs as non-root by modifying the .rpmmacros file in your home directory and set dbpath to relocate the rpm database. Provided you manage dependencies (there are tricks to this) and install to a location you have write access to, this is a good and safe way to use RPM as non-root.

If a frontend were properly set up to allow this, and packages were made relocatable by default, it would work well.

Re:This makes sense

[Culture20]

It makes the assumption that every user is an admin

RMS makes the same fallacious assumption, and throws root passwords willy-nilly to the users.

Re:This makes sense

[jim_v2000]

A) What's to stop a user from providing the root password if malware attempts to install something?

B) If there's already malware on the machine running as the user, there's not much benefit to getting root access anyway. It can log the user's activies, steal info, make connections to remote servers just fine with the user's privileges.

Re:This makes sense

[Wrath0fb0b]

Another way to think about it - you are now vulnerable to local root exploits not only in packages you installed, but also in packages you chose not to install.

Presumably, the now-vulnerable-package will have its signature revoked as soon as the exploit is known. That is, if the implementers were smart enough to have the updater check the latest package list before installing a library -- e.g. if LibFoo v0.81 has the bug, when it checked the list it should see that LibFoo v0.81.1 supersedes that version and refuse to install the older version.

As I understand things (e.g. poorly), this would not be hard to implement. You could own a machine that's not connected to the net, if those exist anymore, by manually moving the file over there, but I believe that is a corner case.

Re:This makes sense

[sten ben]

I don't get it. How does it make sense? To spare you the inconvenience of typing fewer letters you did on that post?

I can only see a single edge case where this makes sense, and that is when the computer is a stationary computer used by a single computer. OK, this is /. perhaps not an edge case over here. But seriously, a lot of people borrow my laptop. I don't want them to be able to install anything without my consent.

As a lot of people in the thread said: This changes XX years of unix practice. $HOME is for users, the rest is for root. Allowing someone who is not root to install software system-wide is not what is expected. Which by definition is bad.

Re:This makes sense

[jonbryce]

Well you needed a password to perform the administrative task of running Winamp until they came up with a new version that fixed it. That is the sort of thing people are complaining about.

Re:This makes sense

[digitalchinky]

Why the hell do I have to 'opt out' of everything after the deed is done? Why not cut the corporate drone some slack and simply ask the question of the administrator during package installation - "Do you want to enable this stupid? Yes / No?"

Re:This makes sense

[Froze]

sudo -s

even easier.:wq

Re:This makes sense

[jonbryce]

If you install it in your user directory, yes.

Re:This makes sense

[Just Some Guy]

There is no such thing as a personal use computer. There are only computers that haven't been compromised by other, uninvited users. When (not if) you get such a visitor, do you want them to trivially take over your entire machine, or do you want their impact limited to the access of the broken daemon that they attacked?

Re:This makes sense

[Nick Ives]

Sudo doesn't take your root password, it takes your password. Also, I'm not aware that anybody with a clue has complained about UAC whilst cheering about sudo. UAC is actually a step up from sudo because it uses a secure input driver to stop a programme clicking OK automatically whereas with sudo there's no equivalent protection from keyloggers.

The only real advantage of sudo over UAC is that you can user sudoers to limit which executables normal users can run whereas with UAC you either have admin rights for everything or nothing, although I suspect you can mess around with user rights in Windows to give much finer grained capability permission.

The only issue with UAC is how annoying the prompts can be and that's because of badly written software that assumes it has to have full admin rights. UAC prompts happen less these days though.

So yea, at least check the facts before posting. Must troll harder!

Re:This makes sense

[DragonWriter]

It makes perfect sense and entirely appropriate for home/personal use.

No, actually, it doesn't. It makes perfect sense and is entirely appropriate in exactly the same circumstances as always running as admin makes perfect sense and is entirely appropriate, i.e., just about none. Obviously, its less disruptive to other people when done in a single-user environment, but non-corporate home use is often not a single-user environment.

Re:This makes sense

[anglophobe_0]

Argh. Think about it. Users can edit some things inside /etc/ (shadow, for instance - every time the user changes his/her password). Users can edit things inside of /var/ (/var/spool/cron/$USER comes to mind). There is a longstanding tradition in *nix of giving users the ability to make changes outside of their home directory where it makes sense. That's the whole point of setuid. So quit debating whether this breaks some sort of unspoken rule, and give some real reasons why it doesn't make sense to provide the access. From a desktop standpoint (Fedora is a desktop OS, not an enterprise one), it makes perfect sense to allow a user to install software that's already been verified as clean of malware without having to escalate their privileges. I don't see how this makes any more of a security risk than allowing a user's gnome session to automount and even autorun their usb stick. And besides, if you don't like it, it's superd00per easy to disable. If you can't figure out how to disable it, you probably should be administering a server with anything remotely important on it.

Re:This makes sense

[fluch]

A) What's to stop a user from providing the root password if malware attempts to install something?

At least there is still a possibility for the user to say: "Oops, I didn't intend this!" Where as in the automatic installation this is not the case.

B) If there's already malware on the machine running as the user, there's not much benefit to getting root access anyway. It can log the user's activies, steal info, make connections to remote servers just fine with the user's privileges.

There is still a chance that the main system does not get infected. There is still a chance that the malware will not be executed when the user logs in again. And it is easier to clean the system if only the user data is compromised.

If the attacker gains root acces your only way to ensure that the system is 100% clean is to reinstall it from scratch.

Re:This makes sense

[fluch]

It makes perfect sense and entirely appropriate for home/personal use. If you're in a corporate environment, disable the feature.

A similar attitude made Windows famous for their herd of malware. So I do not think this is an acceptable attitude to security.

Re:This makes sense

[BeardedChimp]

Having just read through the mailing list then quite of a few comments here most of the people are over reacting through ignorance of the situation:

I may be wrong, but I understand that this behaviour of PackageKit only applies to users with direct console access (i.e. not remote shells). So, only users that are logged in via GDM or TTY would be able to perform such tasks. This significantly limits the number of users with powers to install signed software -- almost to the point of where it sounds like a fair trade-off. If someone has physical access to the machine, then heck -- it's not like they don't already effectively "own" it. Not saying it's a good default policy -- but let's cool our heads. Regards,

So these is really a real world access security vulnerability in which case there are several easier ways to do damage.
Not that I agree with this default of course, it still allows idiots (girlfriends, who am I kidding this is slashdot, your mum) to install crap all over your system.

Re:This makes sense

[caseih]

Wow the FUD flies fast and furious here.

I doubt very much that most Fedora installs even have an administrator, or serve more than a home user. Certainly in a corporate environment Fedora isn't a good ideal simply because it has to be upgraded every year (even if you skip versions). So I find a lot of these arguments to be only valid if you're talking about a multi-user, centrally-administered system, which should not be Fedora to begin with. If you want something RedHat-ish you go with CentOS 5. If you are deploying Fedora in a corporate or educational environment, your admin is going to be hardening and locking down the installs anyway, which is something that PolicyKit finally allows you to do in a nice, fine-grained manner. Admins would want to lock down the mounting of usb flash drives, for example, to remove setuid and execute bits. When RHEL 6 is released, it will likely have much more strict default policies that would be easier to roll out to an enterprise.

Another thing is that most Fedora users I've seen install every last package on the install DVD. Yup. The whole thing. So how's that different in terms of exploit exposure from being able to yum install some-unstable-app?

So given that the most likely person to install Fedora is a home user, I don't see this policy as being a problem at all. Whether or not you have to type the root password, excited newbies are going to install every package under the sun regardless of whether it requires root or not. Further very few people seem to know much about policykit. By default you have to be logged into the console to get most privileges that policy kit allows. So just because some exploits a web app on fedora and gets some kind of shell access doesn't mean they can install rpms without root. But at that point you're hosed anyway. Remote users cannot install packages either, so even if you left this policy in place, it's not like you're at risk to remote users any more than normal.

As I am the sole user, remote or local, of my Linux machine, this is a policy that will be left on. There's no difference between me sudoing yum install blah and just doing it through the privileges of policykit. If anything this will make Fedora more accessible and acceptable to desktop users while still maintaining a certain level of unixy security. IE a virus still cannot get root without an exploit (which would still exist regardless of this policy).

Re:This makes sense

[grcumb]

That's the thing. Every time you see a comparison of security in Windows and Linux, the users in Windows is always assumed to be the administrator, and you get all this FUD about how insecure Windows is. The proper comparison would be to a Windows machine where the user is logged in as a limited user. In that case, it's as secure as a Linux box.

What utter bullshit.

First: Any comparison concerning security is misleading. I don't care if I'm just as secure as X; I only care whether I'm secure enough for a given use case.

Second: Any attempt to compare conceptual levels of security between two different platforms, in which one is responsible for the overwhelming majority of all malware infections and the other is widely understood to be effectively malware-free... well, such a comparison is disingenuous at best.

And lest anyone respond with how vulnerable Linux would be just as soon as X, Y or Z transpires, let me just say that Linux is safe now, today. If it proves to be unsafe in the future, I'll take appropriate action. Until then, theoretical threats are not nearly enough to make me prefer a platform that's theoretically equivalent but in practical terms is orders of magnitude worse.

HTH, HAND

Re:This makes sense

[Kjella]

Well, that's questionable... Unplug the machine, hook it directly to a laptop pretending to be the server but with an old signed package list and old signed packages. You have to fool it into fetching the "new" package list though but launching one of the update tray tools that give you "you have x updates waiting" should cover that without entering any password. As far as I know there's no downgrade protection of package lists so it'll happily accept any old package list and install any old version you want it to.

Re:This makes sense

[IWannaBeAnAC]

Not even that, unix/linux has always allowed users to install software into their home directory. There is very little that can be done to prevent that actually; even on windows, it is only the package management conventions that disallow local installations.

Re:This makes sense

[TD-Linux]

So having a package with a known root exploit in the repository makes sense?

Re:This makes sense

[jmorris42]

> Wow the FUD flies fast and furious here.

> I doubt very much that most Fedora installs even have an administrator, or serve more than a home user.

So many words from someone who can't read. And they said write only devices were mythical. :)

As stated in my post avove, this isn't so much a change in Fedora as a case of Fedora being the first release with this new policykit. If this isn't stopped, flamed into oblivion, shouted down, whatever, it will end up in Ubuntu, Debian, Suse, eventually everything down to FreeBSD because this *Kit crap is infecting everybody. Or it will be individually patched out by individual package maintainers and we all know that is sub-optimal.

And yes even Fedora has users. Even if you are correct that few corporate types will be rolling F12 out to end users there are things called families. I admin my home machine but I'm not the only user. No I don't trust every person I give an account to enough to allow them to have admin rights. Remember trust in the sysadmin sense is more about trust in their skills/knowledge not whether you would loan em a hundred bux.

Re:This makes sense

[jim_v2000]

>Wow, somebody has never used Linux before. This isn't windows dumbass.

I have used Linux on the desktop in various flavors for 4 years now. Don't be a presumptuous ass.

>It makes no sense to have this feature without at some point asking for the root password

If you're not comfortable with it, don't use it. That's what software freedom is all about. People can do what they want.
It makes sense if you want to be able to install trusted apps without having to enter or know the root password.

>With this exploit, you could automate rooting a box without the user ever having to type anything. Its a security hole, and a big bad one.

The possibility is so remote that it's ridiculous.

Re:This makes sense

[jim_v2000]

Does it somehow harm you if someone else thinks that this is a good feature? I'll repeat what I told someone else: if you aren't comfortable with this, don't use it.

Re:This makes sense

[Znork]

The attack surface has been expanded

That was my first instinct as well, but if you look a bit more at the issue it's not much of an expansion. The possible extra surface would be suid binaries, as the ability to install and run programs is rarely secured anyway, only the ability to do it 'the right way' (ie, via package manager into the base system) is secured.

Personally I tend to be more concerned with server systems where this would not be an appropriate default policy (altho package-kit seems to offer some nice granularity in its config), but for end-user desktop systems it might even be appropriate as long as there is a reasonable selection of repositories specified. Even in an enterprise setting it could be appropriate if you think 'customized enterprise repositories' instead of 'random internet repo'.

I'll grump with the best of 'em, but some of the seemingly heinous violations of unixy traditions we've seen in the last few years aren't necessarily completely without thought. But they do require some annoying relearning before one can thoroughly criticize them on a better basis than pure instinct and after doing a cursory examination of package-kit I figure I probably need to rtfm some more before I decide what to do with it.

Re:This makes sense

[jim_v2000]

Why are corporate drones installing Fedora instead of Redhat?

Re:This makes sense

[jim_v2000]

I'm going to assume that if someone can hack into my laptop, they aren't going to need something like this to make it "easier".

Re:This makes sense

[sten ben]

You are of course correct about setuid etc, and although I could argue about expectations a bit more, the rest of my post still stands.

From a desktop standpoint (Fedora is a desktop OS, not an enterprise one), it makes perfect sense to allow a user to install software that's already been verified as clean of malware without having to escalate their privileges.

I think you can find plenty of posts here describing software a person might not want his friend, colleague or brother installing on his computer. But some: GDM, anything with suid root, any networking daemon (yeah yeah, they're disabled on boot, but can still be run)... All users are not *NIX literate enough to root you by borrowing your laptop, but they can still be good enough in a terminal to install a bunch of crap I don't want.

And besides, if you don't like it, it's superd00per easy to disable. If you can't figure out how to disable it, you probably should be administering a server with anything remotely important on it.

Nice ad-hominem there. This issue doesn't apply to servers by the way. And i got out of the admin-business a while ago, so no worries. But: It used to be "easy": pklalockdown –lockdown org.freedesktop.packagekit.package-install but that command is deprecated. In the oh so nice future I'll have to go edit /var/lib/polkit-1/localauthority/50-local.d/10-my-pkgkit-policy.pkla and put some semi-documented commands in it. Most users/admins of Fedora will probably just google it, not read the man page or docs, and end up with a configuration they might not understand.BAD DEFAULT

Everybody just keeps repeating "It makes perfekt sense". I have not seen a single good argument for in what way it does.

Re:This makes sense

[jim_v2000]

Nonsense. The problem is users who will install anything. And this would have no effect, since most users either run as admin, or would pop in the admin password without a second thought when installing software.

Re:This makes sense

[Celeste R]

Reading the thread itself:

the configuration is difficult to change and not in a traditional location, and even then, most opt for a dirty 'patch' designed to turn PK authentication into a blacklist, instead of getting it to work right.

Uninstalling PK is also a no-go, since it breaks packages.

A regular RH user can:

crash the system by filling up / (root installation of packages, so no 5% wall)
install packages with known security holes
install packages that are automatically enabled (PulseAudio defaults on, as do a few others, and I recall a PulseAudio security hole being exploited recently)
install packages from only enabled repositories (the main one in specific is default)

All in all, this is making RH a lot less secure by default than it should be. I'll shy away from RH this time around, tyvm.

Re:This makes sense

[DAldredge]

runas /user:XYZ COMMAND

Re:This makes sense

[moogsynth]

Only because terribly written software was used to writing all over the place all the time. Vista only requires root for the same kind of things linux does. The only other complaint was that it showed an inordinate amount of alerts for the same thing, file copying into protected folders, which was fixed in SP1. I'd still prefer the Vista SP0 4 dialogs to what Nautilus does (i.e, tell me to get fucked.)

One of the major reasons for having the UAC dialogues in the first place was to try and stop developers from writing applications that needlessly require to be run as admin. In that sense, it has been at least somewhat successful. There was a similar purge of root-hogging daemons in Linuxland about ten years back.

Re:This makes sense

[sten ben]

Does it somehow harm you if someone else thinks that this is a good feature? I'll repeat what I told someone else: if you aren't comfortable with this, don't use it.

Of course someone thinking this is a good feature doesn't harm me. Someone deciding for me to change the way my computer looks on software installation might though.

Installing software is a system-level change affecting all users of a system. Those changes commonly require consent of the administrator of the system to apply. That has been the default for ages. Neither you or anyone else has so far made a good case for why it is a good idea to change that default. It's not about if I can disable it, I know I can, but should I have to? Someone (perhaps that someone you are talking about) out there has made a decision for me that I should be using it. That person is not making his case very clear and neither are you.

Re:This makes sense

[sten ben]

It makes sense if you want to be able to install trusted apps without having to enter or know the root password.

You mean like sudo and gksudo? No surely you can't mean them, they've been used for a gazillion years now and work splendidly. And as far as I know no distro has been *ahem* "brave" enough to ship them set to execute apt-get without a password yet.

(gotta say I love your sig though)

Re:This makes sense

[Ozlanthos]

Unless they are generously providing the meeting place for their LUG!

-Oz

Re:This makes sense

[sten ben]

But it does affect me lending my laptop to my mate, or my brother my desktop, for just a while. They're linux-savvy enough to know how to install stuff, but not savvy enough to always know the consequences. If they don't have my pass, they can't install. Simple. Right?

Re:This makes sense

[Sir_Lewk]

Yum won't allow unpriviledged users to install things, those guys aren't idiots.

Ah contraire. If you read the mailing list you will see that one of the idiots supporting this madness is Seth Vidal, the lead developer and maintainer of Yum.

Re:This makes sense

[screeble]

Doomed? The PolicyKit API isn't even stable yet. Doomed might not be a strong enough word.

Jackass decisions like this is why I left DeadRat in the dust a decade ago.

Re:This makes sense

[thejynxed]

That was probably because WinAMP attempted to access IE files, driver subsystem files contained in Windows\System32, etc. since that is what the program relies on to run - even the media library functions require at least the base files of IE to run. IE by default runs itself with higher system rights than the default system rights WinAMP gets assigned when it's installed, triggering the UAC.

Re:This makes sense

[KamuZ]

I agree. Most new applications which actually support Windows 7 can run without prompting everytime for actions.

I remember a few months ago for an application to register the filetypes it can open you had to run the app as an admin, that was the only way.

Now they have the option with the small icon telling you it requires admin rights and of course only ask you if you click on that option.

Pretty much like Mac and Linux have the "unlock" option in the applications.

Re:This makes sense

[MikeBabcock]

So ... sudo gives me fine-grained controls over administrative privileges and UAC doesn't. I see that as a major win for sudo.

Re:This makes sense

[BrokenHalo]

Or you could simply

sudo su

Re:This makes sense

[MikeBabcock]

I have /var/cache and /var/lib as separate LVM partitions, don't you?

Secondly, Fedora is not RedHat. Stop that FUD.

Third, I dare say most users running Fedora are not running multi-user servers with remote clients but rather essentially single-user systems. If you are in fact using Fedora for the former, you'll find SELinux lets you lock down privileges in a way that even PackageKit can't get around.

Re:This makes sense

[Homburg]

The idea of UAC is fine, but the implementation, at least in Vista, leaves a lot to be desired. The most annoying thing about UAC is that a lot of things that you need to authenticate to do also have a confirmation dialog in the application. So you end up being asked if you want to do something, clicking yes, then being asked if you want UAC to allow the application to do that. It almost seems like MS didn't actually test their software with UAC switched on.

Re:This makes sense

[Homburg]

I bet the package sets it to start in all runlevels by default.

You bet wrong. Fedora packages don't set anything to start by default.

Re:This makes sense

[nabsltd]

If you trust only a server under your own control, for example, this could be really useful within an organization to allow users to install company-authorized packages without having to run around and install everything for everyone, while still preventing average users from doing anything to the machine.

Unless you have a lot of custom packages and really small hard drives, you'd never bother with this...you'd just install every package on every machine, and then use the built-in auto-updater on the system to keep every package (custom or distro-supplied) up to date..

Only licensing issues might prevent this, but if that were the case, you wouldn't want users installing the packages on their own, either.

Re:This makes sense

[phliar]

Try this:

sudo su

It has the advantage that you can now type suspend and be back at your regular non-priv user; fg will take you back to root.

Re:This makes sense

[turbidostato]

"sudo bash
works for Ubuntu without ever activating root login. It's what I use when I go in to edit .conf files."

Which in turn shows why sudo is not a security tool.

Re:This makes sense

[jmorris42]

> Ah contraire.

Oh good grief. We really are doomed then.

Re:This makes sense

[turbidostato]

"this could be really useful within an organization to allow users to install company-authorized packages without having to run around and install everything for everyone"

A corporate environment where IT people has to run around to install everything for everyone is already fucked beyond repair and no amount of "really useful" tricks will help with that.

Re:This makes sense

[turbidostato]

"This assumes the user is different from a admin, which is not true for a personal desktop"

He asumes that the admin context is the same as the user context if they happen to be the same person, which is not true anywhere, not even personal desktops.

Re:This makes sense

[Vovk]

I fail to see how not being able to guess the account name of the superuser is a bad thing ^_^

even better, what if you had sudo rights split up between all of your users? O.o It's kinda silly (similar to tinfoil hat linux), but you could have one user for mounting devices, one user for starting certain apps, one user for creating and deleting files, etc...

and we could all type in our passwords by playing tetris in a certain way... that would work!

Re:This makes sense

[Vovk]

Well, that's questionable... Unplug the machine, hook it directly to a laptop pretending to be the server but with an old signed package list and old signed packages. You have to fool it into fetching the "new" package list though but launching one of the update tray tools that give you "you have x updates waiting" should cover that without entering any password. As far as I know there's no downgrade protection of package lists so it'll happily accept any old package list and install any old version you want it to.

You have physical access... There are SO many more convenient ways of breaking into the box than what you are describing...
Still. This is a bad idea. Non-admins installing software that admins may or may not know about... yeah... whoever thought of this should be taken behind the chemical shed and shot.

Re:This makes sense

[Vovk]

It makes the assumption that every user is an admin

RMS makes the same fallacious assumption, and throws root passwords willy-nilly to the users.

That's for FREEDOM man... FREEDOM! I will thank RMS now for allowing me to have my beer and my FREEDOM too!

Anyway, I'm pretty sure RMS's beef was forcing software developers to conceal their actions from each other... I may be wrong though, and then /. will have to correct me :(

Re:This makes sense

[Just Some Guy]

You assume wrong. There are plenty of minor little daemons that wouldn't normally have access to the entire system. Give them the option to install their own suid binaries and full write access to system directories, though, and the entire security model breaks down.

Re:This makes sense

[initdeep]

no it did not.
if a person was following safe computing practice, they would be logged in as a normal user, not an admin user and thus would have a different user/pass and would thus be required to enter an actual password once they receive a UAC prompt.

failure to configure your computer is not a fault of microsoft.
they have enough other things we can blame them for. User stupidity isnt their problem.

Re:This makes sense

[reub2000]

I'm assuming that red hat had to setuid the package manager in order to accomplish this. That itself is a secuirity risk.

Re:This makes sense

[mysidia]

If a root exploit is discovered, the installation of the package can be turned off, or an update can be published: then requesting to install will install the fixed version.

Also, there aren't that many packages that need to start or leave processes in place running as root, those packages could be special-cased...

Re:This makes sense

[Just Some Guy]

If there's already malware on the machine running as the user

I think you're missing the point. I don't care about malware running as the user. I care about a crafted image file that exploits a bug in cupsd, takes advantage of cupsd's newly-granted ability to install software, and exploits yet another package to gain full root.

On a default Ubuntu installation, you also get avahi. Are you 100% beyond-a-shadow-of-a-doubt certain that its networking code is invulnerable so that Joe Cracker down at the mall food court can't compromise the avahi daemon and user? If that were to happen under Ubuntu, the cracker would be limited to running whatever the avahi user has rights to. Under Fedora's new defaults, that includes any software that the avahi user can conceivably install. Not to pick on avahi, but wanted to demonstrate how a previously minor remote exploit on a normally-sandboxed daemon can now turn into a full-blown remote root shell.

But at least it's convenient, huh?

Re:This makes sense

[mysidia]

They probably have a background daemon always running as user "rpm" or something with a UNIX domain socket that accepts UID-verified install commands from a user logged into the graphical console.

And then passes on install commands to some daemon running as root that only accepts install commands from the "package manager UI daemon"

Or whatever... they don't have to use a SETUID bit, they just need an always-running starts-on-boot system process to stand ready to authenticate and implement the request.

Re:This makes sense

[cbhacking]

I suspect you can mess around with user rights in Windows to give much finer grained capability permission

While slightly beyond what I expect a normal user to get, this is very true. Got a game which insists on storing user data in its install folder? Change the permissions on that folder (or preferably only on the files that need changing, or whatever). You can also use Deny permissions to block off access to certain files/folders/registry keys for specific users/groups, even if they would normally have enough permissions to access the protected item.

I've tweaked UAC to behave very nicely for me - new installs or changing system settings still requires approval, but programs that run on a regular basis do so just fine.

Re:This makes sense

[cbhacking]

the difference is that Microsoft, by default, has traditionally made all accounts Admin, and a lot of software vendors have come to depend on that so making a Limited user is an exercise in deep frustration in Windows

The first part of your statement above isn't actually true. Windows has always made the *first* account an Administrator, but upon creating subsequent accounts it strongly urges you to make them standard users (and has that option selected by default). The problem is that most Windows installations just use the default account and never create another, even if multiple people share the computer.

The second part is quite true, although with some clever tweaking of file/folder/registry security settings it's less of an issue. Still, going from XP (standard user) to Vista (UAC) was a major step forward in terms of ease of use and user-friendliness (so many things on XP just inexplicably fail for non-admins).

Re:This makes sense

[raylu]

I complain about UAC while rooting for sudo. The annoyance caused by UAC is not because of badly written software that assumes it has full admin rights.

Firstly, the software is not badly written; it complied completely with previous versions of Windows. Vista and beyond introduced a breaking change; you can't blame the developers any more than you can blame web developers who write code that is not standards-compliant when almost all web browsers render them fine.

Secondly, the annoyance is in the fact that, in UAC, you ask to do something first, and then Windows asks you for authorization. sudo is less annoying because you authorize first (or at the same time, depending on how you look at it) and then ask to do something.

Re:This makes sense

[sjames]

A) What's to stop a user from providing the root password if malware attempts to install something?

Knowing that they didn't ask for something to be installed!

Personally, I run as non-root as a safety measure. When I sudo or otherwise elevate to root access, entering the root password is my psychological cue that says pay attention. I'd like to keep that.

Re:This makes sense

[Blakey Rat]

Firstly, the software is not badly written; it complied completely with previous versions of Windows.

Wrong. It worked, IF you were an Administrative user, but it sure didn't comply with any of Microsoft's software guidelines. Those programs did *not* "comply completely" and any halfway-competent QA department should have caught those bugs on the first day.

If you take "previous versions of Windows" to mean "Windows ME," then you're right... kinda.

Vista and beyond introduced a breaking change;

No it didn't, it just enforced "User" permissions for new computer accounts by default. (Basically... it's more complicated, but that's what it amounts to.)

Secondly, the annoyance is in the fact that, in UAC, you ask to do something first, and then Windows asks you for authorization. sudo is less annoying because you authorize first (or at the same time, depending on how you look at it) and then ask to do something.

I don't see any practical difference between the two. You're just used to the sudo behavior.

Re:This makes sense

[raylu]

Wrong. It worked, ...
any halfway-competent QA department should have caught those bugs on the first day.

So, where's the bug?

Also, when I write software for Windows, my QA team is myself and the two friends I give it to. But my entire QA team gets angry when that software breaks in a newer version of Windows.

I don't see any practical difference between the two. You're just used to the sudo behavior.

The rest of the world, too. When I introduce an XP user to sudo, they seem fine with it. When an XP user is introduced to UAC, even when I explain why it exists and tell them to consider leaving it on (I do), they are annoyed.

Re:This makes sense

[Merc248]

"The root of the problem is that decisions that impact security are being made by marketing people more concerned with the 'year of the Linux desktop'."

# su - problem
problem$ pwd /home/marketing

doh.

Re:This makes sense

[geminidomino]

Actually, it's trivial to prevent that (assuming the admin had the brains to make /home its own partition).

noexec.

Re:This makes sense

[adolf]

They're there. People do see it, that's why there's been the constant stream of complaints that you've seen for the past couple of years from people who tried Vista but "hated it."

Well-behaved software, once installed, doesn't fuck with anything outside of your user directory or a few common areas of the system. This is true of any system that has user accounts. (Note, that not all programs are well-behaved, and not all systems have sensible security to enforce this good behavior.)

UAC will scream at you if a program, run as a user, tries to write to c:\Program Files\*. A lot of old Windows software expected to be able to do just that: It'd write its .ini file in its program directory (for instance), and use that to keep track of settings.

But it's bad behavior. That's a system directory, not to be fucked with. So UAC, again, prompts for permission before continuing with this bad behavior, even though it's necessary for the program to work.

That UAC has never, ever annoyed you is an indication that you're a shill, or that you simply run only well-behaved software.

I suspect the latter, though, so that's why I take the time to explain why people are annoyed: Lots of very useful programs shit files all over the hard drive, because until Vista, it was implicit that they were running as Administrator and could do whatever they wanted without further prompting. That's all changed, now, and the rules are enforced (or at least prompted for). Programs are changing as well to be more compliant with these sensible rules.

I, for one, have been frustrated by UAC. But I recognize what it is, what it does, and that asking me for permission for a poorly-behaved program to behave in an uneducated fashion is a Really Important Thing even for a clued user, so I leave it on. It saved my ass once, and that's worth all the annoyances in the world.

Re:This makes sense

[mrdtr]

Well said!

Re:This makes sense

[lala]

That's not true! I had a guest once.
Turned out she used vi so she didn't stay very long.

Re:This makes sense

[magnus.ahlberg]

Maybe this is obvious to everyone else, but I don't see how this is different from an unprivileged user installing a static binary to his/her home directory and executing it? To me this is just as insecure and possible in any distribution?

Re:This makes sense

[jsoderba]

Secondly, the annoyance is in the fact that, in UAC, you ask to do something first, and then Windows asks you for authorization. sudo is less annoying because you authorize first (or at the same time, depending on how you look at it) and then ask to do something.

That's not the way it works. If you know a program will need elevation, set the "Always run as Administrator" option on the executable or use runas. If you don't know that the program will require authentication ahead of time the program can request elevation when needed, just like i.e. the Ubuntu update manager and other admin tools only request elevation when they need write access to the system. In fact, I'd say many more of the Windows admin tools use fine-grained permissions than on Ubuntu and Fedora.

Re:This makes sense

[Antique Geekmeister]

You usually want "sudo -s -H". That gets you an active shell and the $HOME settings of the root user. Alternative, you can use "sudo -i -H" if you prefer to have root's normal shell instead of your own $SHELL. "sudo bash" inherits a lot of inappropriate settings from your local account, such as home directory and various mail settings.

It's amazing the things you can learn from reading the manual page for an old tool.

Re:This makes sense

[pipatron]

Unplug the machine, boot up with a live CD, install whatever crap you want. As soon as you have physical access to a computer you won.

Re:This makes sense

[Jesus_666]

Actually, I see that as an advantage for UAC. I don't want to have to explicitly run applications as root just because I may at some point want to access a file outside my home directory. That works with single-document shell apps but not a modern tabbed text editor.

I don't want to go through the hassle of having to spawn another instance of the editor from the shell just to edit a protected file, I just want the editor to ask me for my password to elevate (using a system-provided input dialog) and then drop its privileges as soon as possible. Maybe add an option to retain the privileges until the file is closed but that's it.

I greatly prefer the OS X implementation of GUI sudo to UAC (UAC is too disruptive for my taste and doesn't aks for passwords) but, well-written software provided, both are superior to having to manually run the program as root.

Re:This makes sense

[jcupitt65]

sudo implements real privilege separation, UAC (in default mode) does not. sudo is very hard to bypass, UAC is not. UAC is not even supposed to improve security.

UAC's purpose is to make running as admin a bit more like running as a limited user and thereby push developers towards making their programs function well under limited user accounts (the long-term goal).

This page is a good starting point for UAC security, esp. under win7: http://www.pretentiousname.com/misc/win7_uac_whitelist2.html.

Re:This makes sense

[TuaAmin13]

The UAC in Windows 7 is a lot better. Having had Windows 7 installed since RTM release, I've gotten the prompt all of 5-10 times, and that was with installing all of my games, drivers, and random applications.

Re:This makes sense

[TheRaven64]

It's different in a few ways. Firstly, this can install daemons and other setuid binaries that will run as root. If any of these have a security hole then the user can install them, exploit them, and gain root. Not good. The other is that they all go into the default path for every other user. That means that other users can run them accidentally.

Re:This makes sense

[IWannaBeAnAC]

Of course, but that is a rather blunt tool. It also means that users cannot compile their own codes, for example. So it is useless if the users are also software developers.

It also does nothing to stop scripts from running, which is quite significant since you can certainly get some serious software that is written in eg perl, python, or even java. Indeed, there is probably an open source C interpreter somewhere one could use to run pretty much anything. Ideally the interpreter will be itself written in POSIX sh! ;-)

Re:This makes sense

[Cro Magnon]

Even if you are correct that few corporate types will be rolling F12 out to end users there are things called families

What are these "families"?

Re:This makes sense

[tibman]

Escalation has always been a problem though. Most distros repackage the program with their own default configs to fit the distro's "style". Even then most (i hope all!) admins change the defaults before deploying. If you don't like the feature, turn it off! The only news here is that Fedora didn't warn anyone about the change in defaults. It's very possibly they didn't even know.

Re:This makes sense

[magnus.ahlberg]

I see your point, thanks for making it clear.

Re:This makes sense

[Dr_Barnowl]

If it's personal use, anyone who should be installing software will already have root.

Re:This makes sense

[neurovish]

sudo uses whichever password you set it up to use...or no password at all if that's how you roll. Some distros have it use the root password as default, and others use the user's password.

Re:This makes sense

[krelian]

The rest of the world, too. When I introduce an XP user to sudo, they seem fine with it.

Because sudo is a commandline tool and UAC a graphical tool. Sudo behaves like UAC when you try to launch a Gnome or KDE app that requires root.

Re:This makes sense

[neurovish]

Is he? From what (little) I saw of the mailing list thread, his first instinct was to turn it off. That didn't really sound like a cry of support. I hope this doesn't end up in RHEL.

Re:This makes sense

[jim_v2000]

Nothing to do with the topic, but I don't use Avahi...it's like the first thing I always uninstall from Ubuntu. It kills dns resolution on *.local domains.

Re:This makes sense

[bcmm]

The possible extra surface would be suid binaries, as the ability to install and run programs is rarely secured anyway, only the ability to do it 'the right way'

I'm not a Fedora user. Does Fedora not package daemons such that they are added to the appropriate runlevel automatically when installed?

All I know is that Ubuntu does, and Gentoo doesn't. Can somebody fill me in?

Re:This makes sense

[SCHecklerX]

signed != secure.

There are already much much better ways to do this. Like how ubuntu uses Sudo.

2010: The year of the linux botnet.

*sigh*

Re:This makes sense

[BikeHelmet]

What password? I thought it was just a box you had to click, which could be navigated around with AutoHotkey scripts?

Re:This makes sense

[BikeHelmet]

Oh sorry, forgot - that was fixed before Vista came out of RC.

Re:This makes sense

[raylu]

Because sudo is a commandline tool and UAC a graphical tool.

And XP users are already accustomed to the CLI?

Sudo behaves like UAC when you try to launch a Gnome or KDE app that requires root.

That's gksu/kdesu.

Re:This makes sense

[AdamWill]

I'm not a Fedora user. Does Fedora not package daemons such that they are added to the appropriate runlevel automatically when installed?

No. By policy, daemons which would be open to external access should not be enabled by default upon installation in Fedora.

Re:This makes sense

[bcmm]

This is a local exploit. What about other daemons?

Re:This makes sense

[juhaz]

Wrong, Seth is not supporting this madness, although if you just pick one of his comments at random without reading the surrounding discussion and getting the context, you could get the wrong idea.

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

Re:This makes sense

[genooma]

If this malicious software is already running it can easily do any of the following:

• keylog the sudo password and install whatever it wants, or completely trash the system if sudo is setup as Ubuntu's default.
• download a precompiled static version of the hackable software "which has a known security vulnerability to gain root access" and execute it.

Re:This makes sense

[Nick Ives]

I'm not aware of any way to configure sudo to require the root password. In fact, sudo was developed to solve the need to give every user who might require elevated privs at some point from requiring the root password; configuring it in that manner would defeat the point of it!

If you want users to give the root password to run an elevated command then you're best just running 'su -c'.

Re:This makes sense

[jim_v2000]

>What utter bullshit.

Saying that comparing apples to apples is more accurate than comparing apples to oranges is bullshit? Ok...

>First: Any comparison concerning security is misleading. I don't care if I'm just as secure as X; I only care whether I'm secure enough for a given use case.

Fine. In that case, I find Windows to be more than secure enough for desktop and server use.

>Second: Any attempt to compare conceptual levels of security between two different platforms, in which one is responsible for the overwhelming majority of all malware infections and the other is widely understood to be effectively malware-free... well, such a comparison is disingenuous at best.

I agree. It's disingenuous to compare an OS with >1% market share to an OS with ~90% market share. (Yes, I saw your third point.)

>And lest anyone respond with how vulnerable Linux would be just as soon as X, Y or Z transpires, let me just say that Linux is safe now, today.

And I think the last time I had a virus while using Windows was 2003. It was a trojan, which I stupidly got from downloading some pirated app. That tells me that Windows is safe today and for the last 6 years.

User-level package manager

[EvanED]

What I want is a package manager that will do installation to my own home directory -- basically the same as downloading the source and running './configure --prefix=$HOME/whatever && make install' but without the complete bitchness of dependency hell -- without any root privileges at all. Anyone know of one?

Re:User-level package manager

[AnotherShep]

Have you tried just deploying with ClickOnce? Oh, wait, nevermind. :P

Re:User-level package manager

[Defiler]

I know of one for Mac OS:
http://github.com/mxcl/homebrew/
It would probably not be much of a challenge to make that work on a Linux machine. That and a Linux tool for this probably already exists.

Re:User-level package manager

[Nimey]

Stow isn't quite what you want, but it's pretty close. I've used it for just about ten years for locally-compiled stuff.

Generally what I do is ./configure --prefix=/usr/local/stow/[PACKAGENAME-VERSION] && make && sudo make install, then cd /usr/local/stow and type "sudo stow [PACKAGENAME-VERSION]. Removal is a simple cd /usr/local/stow && sudo stow -D [PACKAGENAME-VERSION]. It doesn't worry about dependencies at all, and really all it does is make symlinks in /usr/local/bin, /usr/local/share, and so on.

It would be trivial to set up a ~/stow directory and use that instead of /usr/local/stow.

[PACKAGENAME-VERSION], such as nano-2.0.9.

Re:User-level package manager

[FooBarWidget]

Autopackage.

But it's not just the package manager. Applications have to be modified to specifically support $HOME installation (or, to be more exact, installation to arbitrary locations), and most Unix apps right now don't support this without hardcoding paths during compilation time. This is something which Autopackage tries to take care of too, by providing documentation and code for developers for writing relocatable apps.

Re:User-level package manager

[EvanED]

It doesn't worry about dependencies at all...

So basically, what does it do to solve my problem?

It *does* solve a different problem I have with the Linux way of setting up packages, but I can just change '--prefix=/usr/local/stow/[PACKAGENAME-VERSION]' to '--prefix=$HOME/root' and then everything gets put in ~/root/bin, ~/root/lib, etc. as if ~/root were /usr. That's mostly how I have things set up, so it's a tiny problem in comparison to dependency resolution.

Re:User-level package manager

[EvanED]

Autopackage.

Great for developers of programs, but from what I can tell, useless if I want to install something that someone wrote, which usually use the autotools.

Applications have to be modified to specifically support $HOME installation (or, to be more exact, installation to arbitrary locations), and most Unix apps right now don't support this without hardcoding paths during compilation time.

That's fine... whatever. I'd be perfectly happy with something like a userland emerge that compiled everything on demand.

Re:User-level package manager

[Anonymous Coward]

Nix (http://nixos.org/). You have to have your own glibc, though. As a bonus you can have a few of them without conflicts.

By the way, we allow non-root users to install software - any software. Now, the semantics is such that it doesn't really give user something he couldn't achieve by manually writing a binary: setuid wrappers and upstart jobs are enabled/disabled by root by a process similar to installing packages, but distinct enough. Yes, you can install sshd - you could download a statically compiled version with the same success.

Re:User-level package manager

[Anonymous Coward]

Gobo rootless might be of interest?

http://www.gobolinux.org/?page=rootless

Re:User-level package manager

[miknix]

What I want is a package manager that will do installation to my own home directory -- basically the same as downloading the source and running './configure --prefix=$HOME/whatever && make install' but without the complete bitchness of dependency hell -- without any root privileges at all. Anyone know of one?

ROOT=/home/meLikesStuffAtHomeAndCamelToesAlso emerge something

You can make emerge to install stuff anywhere, don't forget to add yourself to the portage group.

Re:User-level package manager

[jmorris42]

> What I want is a package manager that will do installation to my own home directory.

Both rpm and deb can almost do that. It requires some minor things to change to make it usable.

1. An effort to raise the issue, push the advantages to it, etc.

2. You create a mini tree in your home directory, with a bin, lib, etc. Then you init an rpmdb (or the deb equiv) in that tree. And get the magic right in your login to point the environment variables at it. Then you can install packages into that tree so long as they don't do things only root can do.

3. As things stand now, to install the smallest package into that tree will require installing darned near a full distro which will have packages only root can install. So the one key feature is rpm (and dpkg) need a new switch that allows it to merge two package sets so the user tree doesn't need any package already installed on the main system.

4. Packages which are good candidates for this sort of ad-hoc install need to be checked for any root only activity that could be seperated out into a sub-package for system wide install.

5. To complete the system the update tool would need to monitor your local packages and be able to notify you of updates and then actually do the updates automagically even if you have local repos installed.

5. The graphical front ends would need to be modified to make it all just work. You would run packagekit and click on a package. If you were a mortal user it would just install it into your home directory if it could or tell you to ask an admin if it needed root. Ad icon in the package list would show eligible packages or perhaps grey out package the user lacked rights to install. A power user/admin would get prompted whether to install system-wide or locally.

6. One last touch would be some sort of system to fix duplicate installs. If a user added a package to their private set and the admin later added it the system would need to be smart enough to remove the local version to prevent two different versions from being visible at the same time. It would also help recover disk space.

Re:User-level package manager

[EvanED]

You can make emerge to install stuff anywhere, don't forget to add yourself to the portage group.

Too bad this isn't Gentoo and I don't have root on it.

Re:User-level package manager

[EvanED]

One of my friends has even more stuff installed locally than I do; he gave GoboLinux a try a while (few months?) ago but found the rootless mode "fragile:"

(4:38:11 PM) me: what were your objections to gobolinux's package manager? remember?
(4:38:36 PM) him: oh
(4:38:53 PM) him: The environment it set up was really fragile
(4:39:00 PM) him: I broke it several times
(4:39:09 PM) me: environment variables you mean?
(4:39:11 PM) him: Lots of the pkg config stuff didn't end up being found properly
(4:39:29 PM) him: yeah - rootless mode just isn't tested enough and not quite robust
(4:39:34 PM) him: like you couldn't change PATH and LD_LIBRARY_PATH much or what?
(4:40:53 PM) him: It wasn't picking up libraries that you installed with it properly because it broke pkgconfig files
(4:41:57 PM) him: More specifically, the directory structure they use is cool but they never patched the pkgconfig files, so pkgconfig was always wrong and not much works

I can't speak from personal experience, and I suppose things could have changed since then, but he did drop back to manual compilation.

Re:User-level package manager

[agrif]

Most programs I know of will let you install packages to any root directory you want, to facilitate hand-installation of the operating system and whatnot. You could do that, but it'd also install all the dependencies, too, which is clearly not what you want.

The problem with installing the packages, individually, to different directories, is that sometimes (a lot of the time) installed files have hard-coded paths. I know that, technically, hard-coded paths are bad style, but I can see how sometimes they just can't be avoided. Besides, usually any path changes can be taken care of at configure/compile time.

When you do the compilation by hand, the package knows exactly where you want to put it, and it works. However, when you install a binary package (say from apt) it expects to be in the root, and could (and usually does) fail if it isn't. Package managers don't support this for exactly this reason.

I bet Gentoo's portage has an option, though, seeing as it compiles everything from scratch anyways. If it doesn't, I'm sure it wouldn't be hard to hack into it, being Gentoo and all. Of course, you'd also have to put up with Gentoo...

Re:User-level package manager

[EvanED]

I know that, technically, hard-coded paths are bad style, but I can see how sometimes they just can't be avoided.

Like when? Few (at least semi-professional) Windows programs behave that way. (Visual Studio is a pretty notable exception; it demands to install a couple hundred megs of stuff on your system drive.)

I bet Gentoo's portage has an option, though, seeing as it compiles everything from scratch anyways. If it doesn't, I'm sure it wouldn't be hard to hack into it, being Gentoo and all. Of course, you'd also have to put up with Gentoo...

Emerge has a ROOT variable you can set; presumably this gets passed to configure --prefix. However, I don't know of any way to run Portage without root, and can't find anything about running it on systems that aren't Gentoo.

Re:User-level package manager

[eldepeche]

I bet you can configure gentoo to do this on top of another distro. I used to have a gentoo tree built in my OS X home directory.

Re:User-level package manager

[agrif]

Like when? Few (at least semi-professional) Windows programs behave that way. (Visual Studio is a pretty notable exception; it demands to install a couple hundred megs of stuff on your system drive.)

The difference is in Windows, each program usually has it's own specific directory that can be put just about anywhere, but the executable usually has to be started with a specific working directory, or the executable itself has to be in it, etc.

Linux, and Unix in general, has a strong, historical file system structure that places binaries in specific places, configuration in specific places, and everything else in it's own place. There's even hierarchies for system, user, and computer-local files. Binaries are expected to run with any active directory, from a location that houses all the binaries on the system, and nothing else. A hardcoded path to, say, /etc/awesomed.conf is required!

For trivial cases (applications with no external data) the binary can be moved willy-nilly and still work. You can even move libraries, and update your ldconfig search path. However, often programs expect their data to be in one specific place, determined at compile time, or determined by a fixed-location configuration file. Sometimes you can get around this with small hacks, but not in any way it would be easy for a package manager to do.

Of course, the advantage to this strict structure is that hardcoded paths are almost always correct. Apart from that, it's up to individual preference as to whether Windows or Linux handles this better.

(Now when I say hardcoded, I of course mean compiled-in. I'm not trying to suggest there's just some unchanging string literal in the source, just that there's probably some generated string that gets compiled in after configuration.)

Emerge has a ROOT variable you can set; presumably this gets passed to configure --prefix. However, I don't know of any way to run Portage without root, and can't find anything about running it on systems that aren't Gentoo.

It's been a while since I've worked with Gentoo, but I vaguely remember it's possible to run emerge as non-root, and I definitely remember something about a Cygwin port of it, so that's definitely possible.

Re:User-level package manager

[Anonymous Coward]

zero install: http://0install.net
You run an app through it (using its URL, eg: 0launch http://rox.sourceforge.net/2005/interfaces/ROX-Filer ), and it will install it to a path under your home directory if it isn't already there, and then run it. Not much third-party software available via it yet, but there's an effort in place to change that.

Re:User-level package manager

[Shin-LaC]

That sounded interesting until I read: "Dependency resolution and updates are basic or not working yet."

It's not really a package manager if it doesn't do that.

Re:User-level package manager

[Anonymous Coward]

Yes. Gentoo Prefix.

It has all of the functionality of Gentoo's package manager, Portage, but can be run by an unprivileged user.

Re:User-level package manager

[EvanED]

Wow, that totally is news to me that this adaption of Portage exists.

If you know more about it, perhaps you can answer a concern: if I am using it on a non-Gentoo (non-Portage as the main package manager) system, will it need to go and install all the base libraries and such that it would if it were on a clean system, or would it be able to use the system libraries? I didn't see an answer to that question.

Re:User-level package manager

[tepples]

Autopackage.

Great for developers of programs, but from what I can tell, useless if I want to install something that someone wrote, which usually use the autotools.

Pay "someone" to autopackage the app.

Re:User-level package manager

[EvanED]

Thanks for the response. Still may not be so bad; I bet you can get common dependencies out of the way without much space. Though I'm not sure how much space stuff like Gnome and KDE program dependences have.

Re:User-level package manager

[julesh]

Too bad this isn't Gentoo and I don't have root on it.

Have you considered user mode linux? Gives you a virtual root on your own FS image, doesn't need root to run...?

Re:User-level package manager

[xtracto]

I have always wondered if there was something like "PortableApps" for Linux... there are two or three small explicit efforts thrown by Google search but it would be great if all the apps would be used in Linux too.

Re:User-level package manager

[ynef]

Absolutely. You could try Zero Install[1]. The list of software[2] is pathetically small (it does, however, provide useful apps such as Firefox, Inkscape, and Xara Xtreme), but there are ways of generating your own package. So, you could just generate your favorite packages and either publish them on the web or carry them with you on a USB stick or something. I don't think this will be the future package management system to rule them all, but it is nice to be able to install an app you need without spending ages compiling it (and its dependencies!) or by requesting that your systems administrator approves a request, which could take a long time, particularly if your request is uncommon.

[1] http://0install.net/
[2] http://0install.net/injector-feeds.html

Re:User-level package manager

[TP2k]

Take a peek at Gentoo Prefix. It still requires you to build from source, but it will provide you with dependency resolution. I know people who have run it in $HOME on CentOS boxes.

Re:User-level package manager

[neurovish]

You can make emerge to install stuff anywhere, don't forget to add yourself to the portage group.

Too bad this isn't Gentoo and I don't have root on it.

In that case, ask your systems administrator?

It sounds like you want to setup a chroot sandbox in your home directory since you'll be pulling in all kinds of dependencies to install $foo. I don't think you really want to do what you think you do.

Re:User-level package manager

[neurovish]

Damn...I wonder how long I've been posting in Extrans mode like that.

Re:User-level package manager

[neurovish]

I bet you can configure gentoo to do this on top of another distro. I used to have a gentoo tree built in my OS X home directory.

Yes, it would be similar to what is described in the chroot section of gentoo's quick install guide, but without needing to setup the kernel, grub, filesystems, etc. Basically: create a ~/gentoo directory, install a gentoo stage 3 tarball, chroot into ~/gentoo, emerge stuff. This would require root privileges though, and it doesn't sound like the grandparent has those.

Re:User-level package manager

[Wanon]

rpm2cpio blah.rpm | cpio -vid

cpio is an archive format. cpio -vid will extract this archive to the current directory.

Suddenly you have the contents of the entire rpm in your home dir. Hooray!

Of course there isn't a problem

[TSHTF]

Certainly there can't be a problem here, says the Fedora team. According to the release notes, there are 15,000 packages which can be installed by these unprivileged users. That's a lot of fscking code -- surely some of it is poorly written. Consider this scenario: Package X suffers a critical {local, remote} root vulnerability. If the vulnerability isn't public, any local user (and maybe remote ones too!) has root. If the vulnerability is public, there is often a long window between downstream fixes and Fedora fixes. In either case, this is a security issue. The Fedora team really should have put this in the release notes and reconsider this implementation in the first place.

Re:Of course there isn't a problem

[Anonymous Coward]

Worse than that, consider your same scenario where Package X suffers a critical vulnerability, but the sysadmin is on top of it so checks the system to make sure package X is not installed. Then the next day, random user or malicious user, installs package X without the sysadmin knowing.

Re:Of course there isn't a problem

[Eric Smith]

It's more of a risk because a package can install setuid binaries, or install config files in directories such that they that are used or interpreted by processes running as another user or root. Installing a package can do a lot more than you can do as an unprivileged user.

Re:Of course there isn't a problem

[TSHTF]

Because the package management system runs as root, may install setuid files, or system daemons which contain vulnerable code; an unprivileged user cannot normally do this.

Sure - only signed packages can be installed - but signing a package won't make those pesky buffer overflow vulnerabilities go away.

Re:Of course there isn't a problem

[RAMMS EIN]

Ah, ok. That wasn't clear to me from the description.

So you're saying that a regular luser can install packages AS ROOT without needing to provide the root password, be a member of a specific group, etc etc? And thus, a regular, otherwise unprivileged user can write to directories normally only accessible to root, install suid root binaries, and overwrite configuration files?

Wow.

Just wow.

And nobody raised a big stink about it before the official release.

Incredible.

Re:Of course there isn't a problem

[Too Much Noise]

At least the packages that are allowed to be installed are signed, which means _someone_ looked at them and approved them.

The thing that I would ask here is whether the user can install a specified older version of a given package. Say, for instance, install the original version from the main repository with a know vulnerability that is patched in the update repo.

Re:Of course there isn't a problem

[RiotingPacifist]

but a requirement for signing them can be no-suid or system daemon, that way all this oers is better control over user programs

Re:Of course there isn't a problem

[Nick Ives]

Root is fairly meaningless these days. If you can compromise the user (say via a flash vulnerability) then it's trivial to have your malware run as part of the users login session. Odds are they won't even notice!

Not that that fact makes me feel better about this fedora policy. It just feels wrong somehow...

Re:Of course there isn't a problem

[Anonymous Coward]

The assumption is that *signed* packages are only coming from a trusted source (i.e. the user cannot install their own homebrew package).

Re:Of course there isn't a problem

[juhaz]

And nobody raised a big stink about it before the official release.

That's not really surprising, since it only works on signed packages and the beta rpms's are unsigned.

Nobody noticed because it didn't happen during testing.

Re:It's obvious

[BountyX]

Read the response. It's actually a Red Hat employee making the complaint, calling it a security vulnerability. I wouldn't call a Red Hat employee complaining about this policy to a Fedora mailing list an attempt to coax RHEL usage.

Users should not get to be root. PERIOD

[Jailbrekr]

That is just silly. Users are users for a reason, and admins are admins for a reason. If users want to install software, they can use sudo.

Whoever approved that in the Fedora team needs a refresher in security.

Re:Users should not get to be root. PERIOD

[Jailbrekr]

That is irrelevent. I suspect that a vast majority of Fedora users use standard non root accounts, and only use root for doing system maintenance or installing packages. To allow a non root user to in essence do root commands without prompting for a password just begs to be exploited. the risks that this default setup exposes far outweigh any benefits that may be gained. Is it really that hard to prepend your command with sudo?

Re:Users should not get to be root. PERIOD

[mweather]

What proportion have the admin and a hacker on a remote machine as the same person?

Re:Users should not get to be root. PERIOD

[natehoy]

In a corporate environment, this does make sense.

As a default, it doesn't, because if you're a corporation wanting to extend this authority you'll almost certainly want to spend some time configuring the trusted authority list so you can host "approved" applications on an internal server.

Fortunately, this is a policy setting and not a code change. RedHat should change the default back to "requires root", though, because anyone who wants to change this policy should know what they are doing and make the appropriate configuration changes to control (or not) the applications that can be installed.

Re:Users should not get to be root. PERIOD

[hrimhari]

In a corporate environment, this does make sense.

Really? Here, users are users with no right to install whatsoever in their Windows computers. IT controls that. Just a few power users get admin rights to their PCs.

I don't see the cause of Linux selling very well to IT people when it starts to allow ye olde user install things to the system by default.

Re:Users should not get to be root. PERIOD

[natehoy]

But please read the rest of the post.

"As a default, it doesn't".

If I manage 10 computers and need to install new software for everyone, I'll bop on down to their desks and install it at night, no biggie. I neither want nor need this turned on.

If I manage 10,000 computers, I'm never going to have the staff to do that. So I'm going to set up an internal repository and make approved applications available on it. Then my Linux image could have this feature turned on, along with a customized list of "approved signing authorities" which would be MY repository server (or servers - I might have one repo for finance apps and another for all users, for example).

If the company approves an application, I put it on the internal repo and tell users it's available if they want/need it.

And if an individual user needs something special, I can still use root to install it for them.

Re:Users should not get to be root. PERIOD

[RiotingPacifist]

You don't have to use it, however users can already install and run programs in their /home (noexec can only help so much), making this easier and safer for them (installing trusted packages instead of random ones) is a good idea.

Re:Users should not get to be root. PERIOD

[HiThere]

Letting users us sudo to install software is only acceptable because the right to use sudo is restrictable at the account level. Even so I'm a bit dubious. I'd really prefer if software could be installed to only run in a particular group, and that the installation itself be done with privileges to only the group directories. I *do* understand that this would make the file system more complex, as one would need /_group_/etc, /_group_/bin, etc., but I feel it would be slightly more secure. (Also this would mean that a particular group could have a super-user, who wouldn't necessarily have ANY rights outside the group.)

The odd thing is, I keep thinking that the first UNIX I ever used worked that way. Perhaps it was decided that the extra complexity wasn't worth it.

P.S.: Sorry about the _group_ markup, but /. doesn't support underscore markup, and the italic is frequently too understated in a small area. (And bold definitely isn't what I wanted, and emphasis didn't emphasize noticeably.)

Re:Users should not get to be root. PERIOD

[Jeremy Visser]

What proportion of Fedora installations have the user and the admin as different people?

Hardly any.

In which case, making the user also able to install such packages is a useless feature.

Re:Users should not get to be root. PERIOD

[Simon (S2)]

To allow a non root user to in essence do root commands without prompting for a password just begs to be exploited.

I don't agree. First, we are talking about a desktop distro, and not a server: on a desktop the admin=the user.
Second, if a user with physical access to the machine wants to exploit it, installing a package and searching for something to exploit would be the hard way. Just reboot, enter grub and start with runnlevel 1. There. root.

Re:Users should not get to be root. PERIOD

[Celeste R]

RH didn't give any go ahead, it was the PackageKit upstream that did it without any communication.

Also:
NO documentation about this 'feature'.
Terrible configuration system.
Also, the entire mailing list had to do their own homework about this policy.

Re:Users should not get to be root. PERIOD

[sten ben]

To allow a non root user to in essence do root commands without prompting for a password just begs to be exploited.

I don't agree. First, we are talking about a desktop distro, and not a server: on a desktop the admin=the user. Second, if a user with physical access to the machine wants to exploit it, installing a package and searching for something to exploit would be the hard way. Just reboot, enter grub and start with runnlevel 1. There. root.

I don't agree. First, you're doing it wrong. You should be the admin and the user. Those accounts should not be the same (as implied by the = )

Second, if a user is good enough know how to install stuff, does that mean he groks GRUB and runlevels? My brother does the first, not the last. I trust him with my computer and account any day, because he doesn't know my password, thus can only damage my (backed-up) $HOME.

Re:Users should not get to be root. PERIOD

[Belial6]

Oh how I wish that were true...

Re:Users should not get to be root. PERIOD

[raylu]

So you disallow ping without root, too?

Re:Users should not get to be root. PERIOD

[fluffy99]

But please read the rest of the post.

"As a default, it doesn't".

If I manage 10 computers and need to install new software for everyone, I'll bop on down to their desks and install it at night, no biggie. I neither want nor need this turned on.

If I manage 10,000 computers, I'm never going to have the staff to do that. So I'm going to set up an internal repository and make approved applications available on it. Then my Linux image could have this feature turned on, along with a customized list of "approved signing authorities" which would be MY repository server (or servers - I might have one repo for finance apps and another for all users, for example).

If the company approves an application, I put it on the internal repo and tell users it's available if they want/need it.

And if an individual user needs something special, I can still use root to install it for them.

You're doing it wrong if you have to visit their desks in the first place. If you manage 10,000 linux computers you're going to have centralized management of some sort setup already. In the larger centrally managed linux setups I've seen, it's always a custom setup that no one outside of a couple of admins knows how to run - compared to Windows and ActiveDirectory which just about any MS admin can walk in and manage. But that's another gripe I have about Linux.

Developers vs. Sysadmins

[Anonymous Coward]

Ah yes, the age-old struggle between developers and sysadmins bears yet more sour fruit.

After working as a sysadmin for 10+ years for several groups of Linux software devs, I realized that devs don't make good sysadmins, and vice-versa (in general).

Developer workstations are usually a mess of tweaks, customizations, hacks, extraneous libraries that they were "testing" three months ago, odd daemons, and all kinds of other crap. They would install new packages hourly - so all the better if they could do it without requiring root access to the servers.

Sysadmins on the other hand tend to be uptight control freaks who micro-manage every little thing. This is great when we're talking the company webservers, but when it comes to developer workstations, well... the devs weren't too happy about being locked down.

I guarantee you that this feature was requested/suggested by one or more developers on the team, who thought it'd make their lives easier. And I also guarantee you that most of the people against it are system administrators.

God, I'm glad I went back into Science.

Re:Developers vs. Sysadmins

[BlueParrot]

God, I'm glad I went back into Science.

Science is vulgar compared to mathematics.

I bet you're even one of those dirty experimentalists, or even worse, a chemist!

Re:Developers vs. Sysadmins

[HangingChad]

After working as a sysadmin for 10+ years for several groups of Linux software devs, I realized that devs don't make good sysadmins, and vice-versa (in general).

We did okay in our office. We let the dev's admin their own machines and an actual sysadmin, like yourself, run the production environment. For the desktops users put in an install request and we installed the software for them. It wasn't that hard, we didn't get a lot of requests.

I don't see the conflict myself. Just by running CentOS dev machines and Ubuntu for commodity desktops, we were light years ahead on security without even doing a lot. As long as no one is staying logged in as root, there are much easier targets. It's kind of like the bear joke. We don't have to have bear proof security, just better security than the company next door.

Re:Developers vs. Sysadmins

[huge]

"Physics is to mathematics as sex is to masturbation"

- Richard Feynman

Re:Developers vs. Sysadmins

[BitZtream]

A good sys admin acting as a developer is fine.

What you describe is a shitty developer.

A good developer will develop as a normal user, no development environment I'm aware of actually requires elevated privs for standard development, including Visual Studio using IIS for web apps if you invest the 30 seconds it takes to google for the solution in older versions, newer versions run their own webserver as needed to avoid that problem as well.

A good developer will test on clean machines/fresh installs regularly.

A good developer will test on locked down machines regularly.

A good developer will write an application that doesn't require any specific additional privileges unless they are truly needed, and they'll document what those privileges are and why they are needed.

A good developer has no problem dealing with Nazi admins, the developer will know how to explain EXACTLY why elevated privileges are needed to the admin and what safety precautions are in place or should be observed to limit potential breeches due to those privs.

This problem is a result of cluelessness on the part of the devs who created it, I classify it as a dangerous/critical bug.

Even MS doesn't allow this sort of thing by default. You can trust a particular publisher, which is commonly used in large corps to trust internally developed and signed software, but out of the box, being signed doesn't help you.

Admins act like they do because users with too many privs have a tendency to make their lives hell, so they lock things down to prevent some ignorant user from breaking their system and requiring the admin to do more work, there is nothing wrong with this, especially for company PCs. The biggest problem here is that too many people have this sense of entitlement and seem to think they should be allowed to do whatever they want on their work PC which is simply wrong.

A good developer creates software that a good admin will be happy to run. The only time there is conflict is when one or both of the parties are unskilled and/or ignorant.

I've done both jobs, and currently function as a developer. I started out as a developer, got thrown in the sys admin position working with some very talented people who I learned a great deal from. Now, being back in the developer seat again I can write software that makes admins happy. Which I do, and its used by a few very large and very locked down companies, without any major issues.

Admins that no nothing about software development are a problem.

Developers that no nothing about administration are a problem.

If you've got either one of the above you have a bad situation, but these is no struggle between the two groups, only struggles with ignorant/incompetent versions of either or both.

If, out of the box, this setup allows a user to install a package 'signed' by 'anyone' then the admins have every right to be upset, its unlikely thats the way its supposed to function. Very few admins would take issue with having the ability to allow certain signers to install without elevated privileges, those that do take issue with it are probably more concerned with the fact that these developers have already screwed it up more than the actual feature.

I doubt any dev would want it so ANY package with a valid signature could be installed, theres no real reason for it. I can believe that would like some ability to have installation of certain signers as well though, so again, this is probably a bug.

If by some chance that the intended functionality is that out of the box any package with a valid signature (or for that matter if there is a preset list of accepted valid signers out of the box) then everyone that has written the code, reviewed the code or approved of the idea should not be allowed to write code.

I accept bugs, shit happens, if this is intended as I understand it, everyone involved in this 'feature' that approved of it needs not be allowed to participate in any software development again. Ignor

Re:Developers vs. Sysadmins

[digitalhermit]

Thank goodness for virtualization. I can keep the host system locked down and fairly pristine, yet inside the virtual environment I am a wild man with wild thoughts, eating my oatmeal without a spoon, cutting off mattress tags, and installing beta code wherever I see fit.

Re:Developers vs. Sysadmins

[vegiVamp]

This is why you have
  a) The development environment on the dev's local PCs, where they can fuck about as much as they want,
  b) The development SERVER, where you are willing to install stuff from time to time to get their committed code to run and get real testing,
  c) The staging server, which is kept as close as possible to your production environment, and where code is tested in production-like circumstances,
  d) The production server, surrounded with plenty of slow, painful deathtraps for developers.

Re:Developers vs. Sysadmins

[Culture20]

Your developers don't appear to know what --prefix=~/ means for ./configure scripts.

What does this solve?

[asv108]

I really don't understand the basis for this move. From a desktop usability perspective, having the gui password prompt for an elevated privilege such as a package install works fine. Its seemless in Linux and OSX. Not prompting for authentication for signed package installs is insanely insecure and borderline insane.

Re:What does this solve?

[jim_v2000]

Because of all the signed malware out there? This is a minimal security risk at the worst.

Re:What does this solve?

[asv108]

Its not about Malware, its about security risks in general. If a user installs an FTP server, thats a huge security risk. A signature on the package does nothing to negate the risk.

Re:What does this solve?

[natehoy]

It depends on your environment. For an individual user, you'd want sudo or su and you'd want to be prompted for each install. And that's a good thing.

But in a large corporate environment, I might want to make a bank of internal applications available (similar to Microsoft's "Run Advertised Programs"). I could configure all of my corporate desktops to only recognize the signing authority of a repository I own, then any of my users can install anything they want off that repository. But installs of things not on the "approved" list and therefore in the repository require root access.

However, this configuration setting was still a Bad Move on RedHat's part. If a corporation wants to allow this, they'll probably also want to think about the list of signing authorities they want to use. So this should be OFF by default and if an administrator wants to turn it ON they'd need to take action (and would presumably know what they are doing and why).

Re:What does this solve?

[jim_v2000]

If the user wants to install an FTP server on his own machine, I don't see the problem. If this is a business machine, I don't know why it's running Fedora.

Re:What does this solve?

[BitZtream]

While its unlikely you'll see malware signed in the Fedora repositories, you'll find fairly quickly that 'the bad guys' are the FIRST to comply with things designed to stop them.

Spammers were the FIRST in line to support domain keys AND SPF.

Malware authors were the FIRST to have their ActiveX controls and malware installers signed.

So yes, there is a lot of signed malware out there.

Re:What does this solve?

[Simon (S2)]

I really don't understand the basis for this move. From a desktop usability perspective, having the gui password prompt for an elevated privilege such as a package install works fine.

The first thing I do on my desktop ubuntu install is
%admin ALL=(ALL) NOPASSWD: ALL

Fedora is a desktop distro, and I guess that the user is almost always the admin andyway. And even if that is not the case, becoming root and install stuff on a machine you have physiscal access to is trivial.

Its seemless in Linux and OSX. Not prompting for authentication for signed package installs is insanely insecure and borderline insane.

Why? Personally I don't understand all this paranoia.

Re:What does this solve?

[r_jensen11]

However, this configuration setting was still a Bad Move on RedHat's part. If a corporation wants to allow this, they'll probably also want to think about the list of signing authorities they want to use. So this should be OFF by default and if an administrator wants to turn it ON they'd need to take action (and would presumably know what they are doing and why).

What corporation in its right mind would ever contemplate using Fedora? RHEL, yes, and many are using this. Fedora? Hell no

Re:What does this solve?

[Homburg]

I really don't understand the basis for this move. From a desktop usability perspective, having the gui password prompt for an elevated privilege such as a package install works fine.

It makes sense if you have other users on the machine who should be able to install trusted software, but not perform other administrative tasks - perhaps your child wants to install some games, or your spouse needs some additional graphics application, or something. You don't want to give them full admin access, or even unrestricted access to the package manager (which would allow them to uninstall important stuff).

Now, whether this should be the default is more questionable; it probably makes more sense to have something that can be turned on on a user-by-user basis. But letting at least some users install signed packages without elevated privileges could be quite useful on a home system.

Re:What does this solve?

[Homburg]

Really? An FTP server that doesn't get run automatically, and that can't accept connections due to firewall rules, even if it does get run, is a "huge security risk"?

Re:What does this solve?

[topham]

On that basis, why not create a group which users can be added to that would be allowed to do this?

If you have group "AllowInstall" you can install applications. Done. Problem Solved. Everybody move along.

Re:What does this solve?

[99BottlesOfBeerInMyF]

From a desktop usability perspective, having the gui password prompt for an elevated privilege such as a package install works fine. Its seemless in Linux and OSX.

Usability and security are complementary in this case. Training users to type in their password whenever they need to install software is a usability problem that leads to a security problem of users typing in their password in order to install a trojan with elevated permissions.

Not prompting for authentication for signed package installs is insanely insecure and borderline insane.

While I don't like this implementation, as a concept I think that for signed software the sysadmin has already verified as a trusted source, not asking for the user to enter a password is a very good thing. If only we could get more packages reviewed properly for security and signed. Think of the iPhone App store. Is it insane that they don't ask users to type in a password when installing an app?

Re:What does this solve?

[fluffy99]

What corporation in its right mind would ever contemplate using Fedora? RHEL, yes, and many are using this. Fedora? Hell no

I've seen quite a few mid-sized companies running Fedora on the desktops. Usually it is the sysadmin who think he/she is fully qualified and doesn't need Redhat support, and therefore using Fedora vice RHEL is a cost savings measure. Personally I disagree with that position simply because Fedora is not nearly as stable and has a very fast refresh cycle, which translates into a higher cost to maintain in the long run.

Re:What does this solve?

[Homburg]

Yes, that sounds sensible - somewhere in the thread mentioned in the article, the Fedora devs talk about various plans they have to make this system more fine-grained in future releases, and using a group seems like it would be the obvious way to do that.

Re:What does this solve?

[StuartHankins]

Some of us use Fedora for fileservers in places where RHEL is overkill. We use Fedora 8, RHEL3 and RHEL5.

What a mess...

[interval1066]

The email trail even includes a query from a redhat developer asking why its such an issue. Incredible. I was going to quote some of that thread but the entire exchange is pretty funny, odd, and scary. Remind me to continue to not use RH, at least as a server.

Re:What a mess...

[BitZtream]

Silly is one way to describe it. I think sad is more appropriate.

Potential worm exploit

[crow]

Suppose someone wrote a worm that could get access to the system as a user. Then all they need is to find a signed package with a privilege-escalation bug, and whether it's installed or not, the malware could exploit it, gaining root access.

But apart from that, I can see where this would be nice from a single-user system standpoint.

Re:Potential worm exploit

[jim_v2000]

How does the worm get on the system?

Re:Potential worm exploit

[laederkeps]

If one really wants this on a single-user system (where one is the administrator, of course), one could just allow that special user account passwordless rights to execute the package manager as root. Granted, it's not with signed-packages-only, but it's otherwise the same thing.

/etc/sudoers:
jane cube.janesworld.net = (root) NOPASSWD: /usr/bin/awesome-packager

If an admin thinks this is a good idea, the user is probably using a pointy-clicky type user interface and adding "sudo" before the command in a shortcut is easy and transparent.

Re:Potential worm exploit

[CannonballHead]

Inch by inch.

Re:Potential worm exploit

[RiotingPacifist]

But you can just run the exploit anyway, if you are on a system and you can run binariers/scripts/python/java that call a privilege escalation bug, you can just download an unisgned version of the pacakge and run in,
need your own libraries no problem ldd is here to help

Nobody is suggesting you sign packages with setuid/setgid, so in reality you are no worse in a security perspective than users just installing programs themselves

Re:Potential worm exploit

[El_Oscuro]

Wormable exploits such as MS08-067 require an open port. Since these type of exploits don't require any user intervention, they are very dangerous. If someone gets a zero-day one on a corporate intranet, it is possible to compromise every system running the affected O/S. Most desktop Linux distros are immune to this type of vulnerability since they do not have any open ports by default.

SELinux

[bicho]

Does it uses SELinux in any way? So that only a handful of users are able to install signed rpm packages?

Re:It's obvious

[644bd346996]

This isn't necessarily insecure. Sure, it's not something you'd want enabled on your servers, but for a desktop the only big problems I see are with disk space. (If, on the other hand, this allows the user to install and start a network-accessible service without root privileges, then it's a problem.) For home users, this feature is a definite convenience, and nothing to worry about. For corporate desktops, it's more of a wash: employees can install productivity apps without pestering IT, but now IT has to disable repos that contain counter-productivity apps.

The reason unix has always required root access in order to install software isn't because that's the way things should be, it's because there hasn't been another way to make it secure. Now, if you trust the distro's repos, you can safely let users install those signed packages. This is similar to (but more secure than) Mac OS X's policy of letting users install and uninstall but not modify app bundles.

Re:It's obvious

[mweather]

I think you mean CentOS.

YAY!!!!

[MightyMartian]

Fedora, Now With The Power Of Windows!!!!

Tired of those pesky admin privileges. Tired of using superuser. Want everyone on your system to install what they like, even from websites that say "Install Me!", why Fedora 12 is here! Come on, don't be afraid. Flush forty years of basic security principles down the toilet!

Re:YAY!!!!

[Disgruntled Goats]

And yet when Microsoft included UAC in Windows Vista to address this very complaint they only got lambasted by you same Linux people. What hypocrisy.

Re:YAY!!!!

[Anonymous Coward]

Windows UAC was lambasted because the implementation was terrible.

Re:YAY!!!!

[Anonymous Coward]

Microsoft got lambasted because the UAC started out as sudo from an alternate, evil universe not unlike bearded Spock's home. It got better after SP1 was released, but it still proves the adage:

Those who fail to learn from UNIX are doomed to re-implement it... poorly.

Re:YAY!!!!

[gbarules2999]

Considering all of the Linux people here are blasting this move as much as they blasted UAC (which was a terrible implementation) I don't see what hypocracy exists.

Re:YAY!!!!

[natehoy]

Yes, because as everyone knows, whenever ANYONE speaks about Linux, it's the SAME person who made another previous statement about Linux.

UAC is an excellent attempt at a Windows implementation a proper security model (temporary escalation of authority for a specific task, with prompting). Personally my only complaint about UAC was that it took Microsoft so long to finally come around to something like it. I run XP as a limited user, and it's very frustrating to see all the software that has been written for Windows that assumes you are running as Admin simply because that's the Windows XP default.

And, yes, I'm clearly and keenly aware that Microsoft is not responsible in any way for the laziness or incompetence of third party developers who write code that runs on their OS. But it does point back to the whole issue that's plagued Microsoft all along - security was ignored for way too long in Redmond, and continued as an oft-ignored afterthought well after they had gained a reputation for writing insecure code. I will give them credit - once they finally extracted cranium from anus and got the clue meter off zero, they made a relatively impressive turnaround in security in a very respectable amount of time.

Re:YAY!!!!

[jcupitt65]

UAC is not a security barrier. It is trivial for programs to bypass, especially in win7. Its purpose is to make running as admin a bit more like running as a limited user and thereby push developers towards making their programs function well under limited user accounts (the long-term goal).

This page is a good starting point for UAC security, esp. under win7: http://www.pretentiousname.com/misc/win7_uac_whitelist2.html.

Re:YAY!!!!

[ClosedSource]

Vocal Linux fans are going to complain about Windows no matter what. It's easier to ignore them than to find the few reasonable comments among the flames.

Re:YAY!!!!

[ClosedSource]

Is that the same alternate universe where RMS bathes and Bill Gates created GNU?

I fail to see the problem

[afed125]

This change only applies to Fedora's desktop oriented spins, not the server versions, and it makes sense from an usability point of view. No user should be able to gain root access just by installing a signed package from a signed repository. It might be possible, but since Fedora controls all of those packages it should be easy to prevent that possibility. Overall, I think the increase in usability outweighs the security concern and definitely outweighs the argument of "expected unix behavior". This is someone's workstation or netbook, not a Vax in 1985 with 120 users on it.

Re:I fail to see the problem

[jimbobborg]

You're a stinkin' developer, aren't you?

Re:I fail to see the problem

[sheph]

Well that would be fine if it were an option durring the install, but to make it default behavior seems like a bad idea. I think it's great to give users that choice, but it shouldn't be by default and there should be a flashing warning surrounding the option. We already have enough infected systems on the net, why make it easier?

Re:I fail to see the problem

[bmo]

This is someone's workstation or netbook, not a Vax in 1985 with 120 users on it.

What about computers that are shared among a family? While working in a computer and electronics repair shop, I can't tell you the number of times someone said "Can you figure out what my son did?"

To quote Tom Christiansen again:

"My hunch, and it's only a hunch, is that this is happening because Microsoft and their moronic minions simply cannot for the all the tea in China ever manage to think outside of their quaint but completely fictional little single-user universe."

Installing software is a root function. There's a reason why it's been that way for decades. Allowing ordinary users without some sort of gateway (password in sudo) to install even signed packages is madness. Ignoring the fact that computers are used by more than one person is ignoring reality.

There is a point where "user friendliness" becomes harmful in the long run. This is one of those cases.

--
BMO

Re:I fail to see the problem

[XSpud]

This is someone's workstation or netbook, not a Vax in 1985 with 120 users on it.

But that workstation or netbook might be behind a corporate firewall on a network with 120 other users.

I don't get it...

[Junta]

If it *is* a desktop scenario, then controlling it via sudo shouldn't be a problem. If you don't have sudo access, I don't see why you should get to install packages...

Second, a vulnerability is found in an apache package in fedora 12, and the repo is fixed, but vulnerable versions from release may be had by crackers. A fedora server with multiple users that doesn't happen to have apache installed is vulnerable to having the vulnerable package injected by an untrusted user.

Require Password Instructions

[BountyX]

Browsed through the list. Here are instructions to require a password for signed repo. I agree with many of the mailing list users, this is a very bad default and there seems to be an assumption of targeting the desktop, or single user environments...

Re:Require Password Instructions

[sten ben]

You beat me to it. And to reinforce that for you:

there seems to be an assumption of targeting the desktop, or single user environments...

Raise your hand if you've lent your computer to a user who wouldn't know how to root your box but wouldn't have any problems finding a package in a list. Would you want that user to install one of 15 000 packages?

Re:Require Password Instructions

[Xtifr]

Raise your hand if you've lent your computer to a user who [...]

Indeed, my nine year old niece has an account on my main Debian box. I trust her completely with the standard user privileges, but I really don't think I want her installing random stuff. My HD is decent-sized, but I'm not sure it would hold a pony. :)

Re:Require Password Instructions

[sten ben]

Nail firmly hit on head :)

Re:It's obvious

[bmo]

The best rant against the Windows way of doing things from Tom Christiansen:

http://slashdot.org/comments.pl?sid=3291&cid=1395315

No, I don't care that a customer asked for it. Customers are idiots, just like any other user. So what if they pay you? They're still idiots, and it's your professional responsibility to act responsibly, to refuse to go along with their madnesses. The customer is not always right. In fact, they're very often wrong. A physician or a lawyer doesn't do whatever the customer requests, and neither do you. They, meaning the customers or users, simply don't have the background and training;

Truer words were never spoken.

--
BMO

Hmm...

[fuzzyfuzzyfungus]

I'm not sure that this is a good default setting(though I would say that it is much more defensible for a desktop oriented distro, with the ability to turn it off; while it would be unsuitable for a server/corporate lockdown box setup). However, aside from the on by default/off by default question, I don't really understand what the big deal is.

Some people are freaking out, as though context-sensitive privilege escalation is some sort of ghastly betrayal of all that is UNIX and Good(tm). That seems frankly nonsensical.For example, good old Sudo does exactly that. If you are on the sudoers list, you can do some or all things as a different user(usually root) with just your own credentials. This is wildly useful, and is a routine part of a great many UNIX systems. In desktopish contexts, we've also had things like automounters for external storage, doing a limited amount of trusted stuff as root, for some years now. Not necessarily the thing for servers; but usually good for desktops.

I don't know whether this is a good default or not, and I'd certainly want to see it mentioned in the docs(assuming it isn't already, haven't checked). However, limited privilege escalation mechanisms, for performing a set of trusted actions, have been part of UNIX for years. Anybody who is merely blowing up about that, rather than about the defaults question, is being reactionary in a way that isn't even accurate.

Mandriva's rurpmi

[Zombie Ryushu]

Mandriva had a function like this called rurpmi. (r as in "restricted") that would allow sudoers allowed only rurpmi to install (Signed) packages. I'm not sure if this is exactly the same thing.

Re:It's obvious

[eqisow]

Well... last I checked installed network services were started audomatically, which may be bad practice in itself.

You laugh, but....

[WindBourne]

MS is hit hard because they have had similar bad ideas, combined with having hired bad developers (and getting worse). But MS is now focused on Security, and is slowly making progress. I fear that if and when they surpass *nix (Linux, BSD, OSX, and some of the smaller ones like Solaris :) ) in security, that *nix will suddenly be slammed with virus and worms. And it will appear to happen overnight, even though it will be possible openings like this that slowly turn the heads of the writers.

Re:You laugh, but....

[Romancer]

They're in for a long battle.

Considering that the fix to this is already written out in one line of code in the same thread on the same day here:
https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01055.html

And they have already admitted that the default security setting is not consistent with the philosophy they had built the Linux system on in the past. That's a pretty good turn around time for a mistake in the security area of an OS.

Re:You laugh, but....

[Requiem18th]

Ok, ok, I'll fix that...

If I had mod points I'd mod you FUNNY.

There! Are you happy? I had to take that letter from elewhere!

Re:You laugh, but....

[Alex Belits]

Or we can simply not allow users to install software if they are not admins.

Oh wait, this is exactly what we are doing now.

Re:You laugh, but....

[hairyfeet]

But you HAVE TO allow users to access root and install software, because home users ain't buying this thin client crap. Which of course means Velma will install ANYTHING, or hand out root access to anyone for any reason, and there you go. It is the home users which are the big market today, and it is those same home users who rarely have an admin and have to be given the keys to the kingdom. Sorry, try again.

Re:You laugh, but....

[Alex Belits]

because home users ain't buying this thin client crap.

If home users have someone else doing administration (usually a relative), that user doesn't have to be able to install software. It would work the same way in Windows if not Windows' piss-poor security model and applications' insistence on having excessive permissions -- problems that never existed in Linux.

Re:You laugh, but....

[hairyfeet]

And if we all grew wings out of our butts we wouldn't need cars! Why do you think there are so many Windows repair shops? Why do you think that nearly every little town has at least one, and in my little town of 15k there is me and two other shops, all doing decently?

Because there is NOT someone doing admin for the vast majority of folks. They go out to Walmart, Best Buy, or Staples, and pick it up like one would a toaster, and they often know less about it then they do the toaster. They see a shiny, they want the shiny, they INSTALL the shiny, they get pwned. It really ain't hard to follow.

And Linux would NOT do a dang thing to help those folks, because once word got out your nice friends in the RBN, along with their friends in Nigeria and China, would be writing "Happy_Puppy.SH" and "Hot_Lesbians.deb" along with nice handy instructions on how to run it. And they would, oh yes, they would. Just for the hell of it I tried putting the "lesbian" guy on Linux, either PCLOS or Mepis, whichever one had the latest release at the time. He managed to completely break the thing beyond booting in THREE DAYS! How did he break such an easy and secure OS? Simple, he decided he didn't "like" package managment so he went to Google and looked for "Linux programs" and anything he found on there he thought was cool, he ran. Ended up in dependency hell.

To quote Forest Gump "Stupid is as stupid does" and I don't care how idiot proof you think your OS is, trust me, there are even worse idiots. That is why we have words in the biz like ID10T and PEBKAC. Linux is fine on servers with competent admins, and on corporate desktops that are locked tighter than a nun's thighs and have guys being paid big bucks to admin them. But that is NOTHING like the home market, not in any way, shape, or form. Home users will NOT buy support contracts, will NOT pay you to come out and be their admin, and will NOT let you lock them out of installing crap. With the home users all you can do is give them a good AV and set autoupdates, along with coming along behind and cleaning up the mess. Trust me, with nearly a decade and a half in the repair biz I know of which I speak.

LOCAL USER ONLY, AND SIGNED PACKAGE ONLY

[QuoteMstr]

There's something really, critically important here that everyone is missing:

ONLY LOCAL USERS CAN INSTALL PACKAGES

In other words:

IT ONLY MAKES A DIFFERENCE FOR USERS PHYSICALLY SITTING AT A MACHINE

That means that a random user can't ssh into your server and install packages. He has to actually be at the machine. And if he has physical access to the machine, he can just boot from a LiveCD.

Installing signed packages is a very low-risk operation. Yes, there are theoretical vulnerabilities, but in order for them to make much of a difference, you need the perfect alignment of coincidences that's really unlikely in practice.

This change allows users who can already compromise the machine given enough time do something very safe painlessly.

Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY

[Junta]

Either that, or someone able to fool the checks for console ownership (one of the points in the email thread were that the checks weren't sufficiently robust for their comfort).

Every package from the project is signed. It doesn't 'lose' its signature just because a new rpm exists in the world somewhere that fixes a vulnerability. So a system that doesn't want to run 'extremeliabilityd' and opts not to install it at all, could be compromised anyway.

Why would one want to imitate the Windows 95 model for deployment security?

Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY

[blueg3]

Yes, only the console user can install packages.

Or, any software the console user is running?
Or, perhaps, a web page that the console user is viewing through a web browser with a security vulnerability that enables remote code execution?
Or, perhaps, an ad embedded in a web page that...

Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY

[RAMMS EIN]

You are right that the idea is that this only applies to the scenario where there is, essentially, a single user who owns, operates, and physically sits at the PC, and that a lot of people seem to be missing that.

However, if you own, operate, and physically sit at your PC, how onerous would it be to have to enter your password, or even the root password, when you want to do something as disruptive and uncommon as use the package manager to make system wide changes?

And if that is indeed too onerous, how bad would it be to have to change the configuration to allow you to do same without having to enter a password?

In either of those cases, you would have a secure-by-default design. Deviating from that just opens a huge can of worms (no pun intended), as there are suddenly a lot more things you need to worry about - and failing to worry about them gives you an insecure system.

Doing something as unexpected and potentially dangerous as this should NOT have been done without ample discussion, and should definitely have been mentioned in the release notes and during the installation procedure - probably with an option right there to turn it on and off, and probably with the default being off.

The mind boggling WTF here isn't that somebody thought letting users install packages without having to enter a password is a good idea, but rather that the new, disruptive, less secure setting has been made the default without the world, the users, or even the developers knowing about it.

Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY

[Lemming Mark]

Worth noting the corollary - (only) console users are susceptible to any malware they happen to get (ab)using the package system. Assuming an absence of malware running under a user account, it makes a good deal of sense to let users with physical access install new packages, in fact it sounds very useful indeed. Thanks for pointing this out as it does make a huge difference that the feature is restricted by default to local users!

Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY

[Kjella]

Wouldn't it be trivial for a remote user to alter stuff in the user's home dir to install it next time someone logs on with a local user? I think this defense only works if the user never logs on locally, which is very unlikely for a home machine.

Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY

[BitZtream]

I've got a box sitting right here, I'd love to see you boot from a LiveCD. Not real sure how you're going to do it considering the CD isn't part of the boot sequence and the BIOS is locked with a password.

You could try to move the drive to a new machine if you'd like, but since thats going to require you digging it out from behind a table, with several large items sitting on top of it, I'm probably going to notice you doing it. Did I mention the case also has a lock on it?

I let plenty of random people use it, its a shared workstation in a hotel for guests to use.

Now, with that in mind, how safe does it sound now?

This is a retarded policy choice no matter how you look at it by a couple of douce bag milkshakes who shouldn't be allowed to commit to any repository on the planet, even their on personal one.

Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY

[Spit]

There are too many assumptions: the implementation is flawless, that the input is indeed on the console and not from hijacked controls or remote desktop, that the user hasn't been engineered into adding a bad repo key. This is just poor.

Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY

[Xtifr]

Yeah? And my NINE-YEAR-OLD NIECE regularly sits at my computer! PHYSICALLY!! And no, I DON'T WANT HER TO INSTALL RANDOM STUFF! And no, I'm NOT WORRIED ABOUT HER ROOTING THE MACHINE. But I STILL DON'T WANT HER INSTALLING RANDOM STUFF! I trust her, but only so far, and she might start to wonder what this telnetd package is.... She's nine!

Does my SHOUTING IN BOLD-FACED CAPS help get the message across, or is it as annoying and pointless as it was in your post? :)

Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY

[sgtrock]

My kids have had direct, physical access to the desktop on a shared machine since they were old enough to see the keyboard and move the mouse. My now 15 year old daughter started that way when she was 3. Do you really think it's a good idea to allow a THREE YEAR OLD GIRL the ability to INSTALL ANY SOFTWARE WHATSOEVER????

Whoever thought that setting this as the default was a good idea should be shot before they contribute to the gene pool. Anyone who thinks this is a good idea for any distribution deserves the rooting that they're about to get.

Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY

[ClosedSource]

Some people might question the idea of a three year old using a computer in the first place.

Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY

[bcmm]

Everybody needs to be able to type well now, the same way everybody needs to be able to write legibly. As with writing, you might as well start as soon as you're physically able to operate the pen/keyboard.

Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY

[StuartHankins]

The vulnerability is extended to anyone who VNC's into a system. There may be other attack vectors as well.

Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY

[ClosedSource]

I'd say that being able to type well has become an obsolete skill since we stopped using typewriters.

If you never had to use a typewriter, you can't appreciate how liberating an erasing backspace key is.

One way to root a Fedora install

[mukund]

Fedora accepts all kinds of packages. You could create a simple utility, like some netmask computation code, make it a trojan (add code which does what it's not intended to do as setuid root).. package it for Fedora. This can go completely unnoticed. As an upstream maintainer, I am pretty sure Fedora or any other distro does not review my project code more than a cursory glance to fix any compilation/integration issues.

User gets to be root user. It may not even be a user.. it may be a program of some kind that has access to your user account after exploiting a vulnerability in an app such as your web browser.

There are other ways to get root too, such as exploit other setuid binaries in any of the thousands of packages that Fedora ships in the Everything repo.

Letting users install packages (signed or not) on a system administered by root is a stupid decision.

Let's see who can speak more about this issue...

[icepick72]

.. the ./ community, or on the mailing list thread. Bets anyone?

100 posts is nothing!

[kimvette]

"at which point it sparked a mailing list thread that is, as of this writing, over 100 posts long."

Pfft. 100 posts is nothing. Consider your audience; this is slashdot!

Re:100 posts is nothing!

[bsDaemon]

Yeah, but most of those 100 posts were probably actually read before getting responded to

Of course!

[RoboRay]

They had to do this in response to Microsoft patenting SUDO.

Re:It's obvious

[edittard]

On Windows, only admins can install.

So only 99% of users?

Interesting comment on Bugzilla...

[bheer]

Interesting and wrong, I should say:

There's nothing to discuss here. Your problem is that pretending asking for root authentication for *local* users in *active* sessions... when installing *trusted* software adds security is... well.. only a sign of dogma, snakeoil and ignorance when it comes to providing a secure system.

There's a superficial kind of sense in what he's saying. After all, if someone has console access, he could already pwn the machine, right? Well, the keyword here is defense-in-depth. There are lots of reasons non-root, non-trusted users might want to run from the console. Linux on random net-cafe machines is one example, where all kinds of people use the console. A family PC running Linux (hey, not as farfetched as it sounds) might have different user accounts for each family member.

Sure, it's trivial to fix this with pklocalauthority, but should users have to? It's about as lame as telling folk, "hey, you can just switch off IIS if you don't need it."

It's sad that while Microsoft and Windows has made so many strides towards providing a secure-by-default configuration, Red Hat seems to be losing the plot. Cf another gem of a comment on Bugzilla: I don't particularly care how UNIX has always worked. Sigh.

Re:Interesting comment on Bugzilla...

[sten ben]

Cf another gem of a comment on Bugzilla: I don't particularly care how UNIX has always worked. Sigh.

God. Reading that thread made further reinforced my commitment never to install Fedora. I would dearly like to see the "use-cases" that Richard Hughes fella has dreamed up to rationalize this change.

Re:Interesting comment on Bugzilla...

[alien_life_form]

Greetings.

The two comments you quote have been posted by the developer that appears to have made the change in the first place. In his blog, he also explains how that is part of the "philosophy" of the application, and somesuch.

It is also of interest that other developers on the same thread appear to be on a similar short fuse (see comment #144). There is a very annoying tendency (on the bug coments and the ML) to simply tell people who argue against this behavior to either add more justifications (as if they were actaully needed) until they are blue in the face or to shut up (or, sometimes, just the latest).

It has basically turned into an ideological war, and it's ugly to behold.

Cheers,
alf

Re:Interesting comment on Bugzilla...

[StuartHankins]

Mod parent up. Finally, someone "gets" it.

Re:Interesting comment on Bugzilla...

[Bazer]

This issue isn't exclusive to Fedora. PackageKit is (or was) destined to be the package and update framework for many distributions. Fedora got hit first because it's the distribution which usually had been going for the cutting edge. Fortunately everyone else will be spared the hassle of damage control and setting the developer straight. This whole uproar may inspire a better focus on scrutinizing the whole *Kit approach, which is IMO a good thing.

I'm not sure about the current development structure but I think it would be optimal to get more developer feedback from other distributions on the *Kit framework. This project looks like it really could use more transparency and QA, especially when it's going to be responsible for desktop security across many distributions.

I don't particularly care how UNIX has always worked.

Let's hope that quote won't get him a place in the "famous last words" fortune of UNIX security.

In some cases it could be ok...

[atmurray]

As long as the program never runs with privileges different than the user installing it then it's not really a concern. In fact, it's not really any different to the user running whatever software they want in their home directory. However, as pointed out by many before, if the program runs with elevated privileges or under a different username or even worse, as root, than it becomes far too dangerous to allow. Hopefully a sane compromise can be achieved like only requiring root privileges to install programs that run elevated.

How about signed non-suid non-services?

[Captain Segfault]

The big security issues are with services and suid/sgid binaries. As long as installing the package doesn't cause any other users to run that code it shouldn't be any more of a problem than letting the user run their own code. Those probably should require root to install.

This isn't 100% watertight but would drastically reduce the scope for local root exploits.

It'd be stupid to have this policy on a server, obviously, but it doesn't seem to be that absurd at all for desktops/workstations.

Re:How about signed non-suid non-services?

[Captain Segfault]

The other big thing would be to require that the package is the most recent version in the repository. That alone would eliminate most non-0-day security issues -- assuming, obviously, that any such issue will get a prompt security fix.

That could be combined with a non-root-install blacklist in case there isn't a good fix.

I wouldn't be tremendously worried about J-random-user's desktop being compromised by a 0-day exploit...

Re:It's obvious

[VGPowerlord]

You beat me to it!

I should take the time to play around with CentOS sometime, rather than just sticking to Debian (and Ubuntu).

Easy way to disable...?

[ehrichweiss]

This can theoretically be easily disabled by chmod'ing to everything under /etc/yum.repos.d as 600, and of course making sure that everything there is owned by root. Assuming this doesn't extend to rpm, and my initial tests suggest it may not, then that should be enough to lock it down for the most part. This is preferable to locking down the yum binary since a user could just bring their own binary to the system and then install at will. I'm sure my method could be bypassed but I haven't had a lot of time to test so someone else feel free to test it.

Re:Easy way to disable...?

[Znork]

A more 'correct' way to disable would probably be something like what's described here.

Editing the package-kit rules also seems to make it possible to obtain some finer granularity that doesn't seem as unpalatable as sometimes inappropriate general install rights.

Re:Easy way to disable...?

[ls671]

I do not know much about the inner working of yum, my distro doesn't use it so bear with me if my comment sounds stupid ;-)

At first glance, it sounds to me that if a plain user can install packages on a system outside its home folder, he must be granted root privileges through a setuid program somewhere along the path or be granted sudo root permissions. So why not just remove the setuid bit on the culprit program or remove sudo privileges ?

Removing setuid bit on some programs is a normal step for me in hardening the security level on any system. It seems to me like a more straight forward and surer way to close potential holes. By changing configuration parameters, one needs to actually look at the source code of the programs in order to make sure that the potential holes are actually eliminated.

Re:Easy way to disable...?

[juhaz]

I'm not sure what makes you think that would work. Something in the machinery is obviously granting root privs to the relevant process(es) at some point, or it couldn't work without support from rpm, and that being the case, it'll likely to be able to read 600 files just fine.

Note that it doesn't extend to yum either, so locking down the yum binary would be useless, packagekit is different beast entirely.

Re:Easy way to disable...?

[ehrichweiss]

I actually accidentally discovered it BEFORE FC12 was released when I moved a .repo file I had downloaded as a standard user to /etc/yum.repos.d and then chown root-ed it with the 600 permissions I had previously set to it.

Usually when I'd do a "yum update" or whatever without using sudo, I would get "you need to run that as root" but instead afterward I got an error about being unable to read that particular repo and then yum exited. That behavior still holds even after the recent patch.

I don't actually use packagekit so I have to ask... Have you actually tested this to confirm or deny it or are you merely giving conjecture?

Re:It's obvious

[Martin Blank]

Trusting the repos has nothing to do with it. If I've got my users on Fedora as their desktops, I don't want them installing packages that I don't know about. Why should the average user have a web or FTP server running on the desktop? Default configurations have frequently been the location for vulnerabilities, and many users could install a service and then not be able to secure it properly because most of those configuration files require root or sudo access.

While the Fedora devs seem to think that Package-Kit should be removed from servers, this is, as one poster mentioned, a case where "should" has nothing to do with it. I have an expectation that I have to either use sudo or provide a root password to install even the smallest package. Changes like this render that expectation void without doing a proper job of notifying me, and there are a lot of relatively unsophisticated Linux admins out there. There's only a certain level of coddling that should be done to avoid oversimplifying things, but this breaks a fundamental premise of the Linux world, and I don't recall seeing anything in the installer saying that Package-Kit's installer would work differently.

Forget vulnerabilities, think telnetd

[Xtifr]

Unless there simply isn't, e.g., a signed telnetd package, you don't need undiscovered vulnerabilities for this to be a potential for major problems. Many packages are not the sort of thing you would really want to have on, say, a publicly accessible machine, but might be willing to have on a system on your LAN (Samba springs to mind). Beyond vulnerabilities, there's the simple issue of exposure.

If the admin can't define who is allowed to do such basic administration tasks as installing packages, something is seriously wrong!

Re:Forget vulnerabilities, think telnetd

[julesh]

Unless there simply isn't, e.g., a signed telnetd package, you don't need undiscovered vulnerabilities for this to be a potential for major problems.

Installing telnetd doesn't make it run; you'd have to add it to inetd or run it manually, either of which require logging in as root.

Installing software is rarely an issue, it's only running it. Stuff that installs setuid root needs careful examination, but there's little enough of that that I'd guess they've audited it quite thoroughly over the years...

Denial of service attack?

[seandiggity]

Besides the obvious problems with this that I've already seen posted here... Couldn't a user install everything from an approved repo and crash the machine by filling up all the disk space? Seems like an attack vector for denial of service attacks.

Re:Denial of service attack?

[Simon (S2)]

Besides the obvious problems with this that I've already seen posted here...

Couldn't a user install everything from an approved repo and crash the machine by filling up all the disk space? Seems like an attack vector for denial of service attacks.

Sure. But since we are talking about local users that have physical access to the box anyway, why should they DoS it by installing packages? They could just throw it from the 11th floor.

Separation of root binaries/local binaries?

[vosester]

Isn't this just a separation of root binaries/local binaries, I mean if the packages are signed and placed in a users dir and the user can not install unsigned apps. Then I seen don’t really see a problem with this. It might increase the attack vector a little bit.

But I could see this helping in a corporate environment. Admin could deploy a standard set of apps, and the different department would deploy there own, Then the user could use his own personal email and browser that best fits with there workflow.

I will properly stick with the Debian/Ubuntu way, but I an not blankly ruling this out as a deployment method until I know more about the pros and cons.

I think the reaction is a bit over the top

OMG!!!! my box will get pwned

I will give the Fedora devs a chance and run this in a virtual machine for testing.

Its the same with all operating systems what are the default policies for the systems?
Why do you think there is 1001 flavours of linux no one distro, Will fit all ways of administration.

Re:sounds good to me

[Lord Bitman]

this basically means "I allow you to install any package which I have signed. You don't need to log in as a more-powerful user to do so, because I have already pre-approved this action, just as if I added the specific command to the sudoers file with no password"
The default signature is that of redhat, but there's no reason to expect the same technique couldn't be used for other signatures. Sounds like a good idea, especially for a corporate environment (single deployment, but if some people need to install Eclipse, they don't need to contact support to do so)

The next step along the line is to tie this into the existing "that command doesn't exist, install Foo to use it", to turn that into "Foo isn't installed, do you want to install it?" and a (sorry) windows-style "how recently was this used?"/auto-remove-during-updates and make the whole operating system feel entirely seamless in terms of application usage.

This is a good thing.

How to disable it...

[sten ben]

Here's a blog post on how to disable it: polkit and package kit and changing settings

I might be getting a bit conservative in my old age but what of what is explained in that post is better than visudo?

Re:It's obvious

[Penguinisto]

If you're doing it corporate-style, you should already have a local repo (for bandwidth and security reasons), them lock yum.conf to only recognize your local repo.

Doesn't solve all permutations (e.g. discreet downloaded packages, some idiot installing apt-get, etc), but it solves enough of them to make things sane again.

Re:It's obvious

[Anonymous Coward]

The best rant against the Windows way of doing things from Tom Christiansen:

http://slashdot.org/comments.pl?sid=3291&cid=1395315

No, I don't care that a customer asked for it. Customers are idiots, just like any other user. So what if they pay you? They're still idiots, and it's your professional responsibility to act responsibly, to refuse to go along with their madnesses. The customer is not always right. In fact, they're very often wrong. A physician or a lawyer doesn't do whatever the customer requests, and neither do you. They, meaning the customers or users, simply don't have the background and training;

Truer words were never spoken.

--
BMO

The trouble is I have encountered both physicians and lawyers who WILL do exactly whatever the customer requests. With lawyers, they often get beaten down by the judge, but they still took the clients money in exchange for bad advice. With doctors, people become over-medicated, misdiagnosed, and sometimes dead.

Re:It's obvious

[countach]

A web server, no they shouldn't be allowed. But basic user level apps, why shouldn't they be allowed, at least as a default policy for a shipping OS?

Re:It's obvious

[cookie23]

It is necessarily insecure: At any point in time there can exist signed software in the repo which the user can install and which has known exploitable vulnerabilities. Therefore it follows that malicious code running as the user can, without root privileges, install said software and then exploit the vulnerability automatically and without the users knowledge. Its just a matter of effort to create a virus/worm that quarries for current unlatched packages and exploits them or runs in the user context again until such time as it can. Once root the policy is exploited once the policy can be used again by adding a malicious, but now trusted repo so the user code can keep getting root and reinfecting in the future as needed. This is a path to turn a malicious unprivileged user exploit into a system exploit, not unlike the many IE cross-zone security problems of the past.

easier way

[eqisow]

There's an easier way...

Re:easier way

[ehrichweiss]

I wouldn't call that "easier". I would agree that it is the "proper" way to do it but it is definitely not easier than typing "chmod -R 600 /etc/yum.repos.d"...;) But the method you, and someone else above you, pointed out will likely be how I handle this...so thanks.

Re:It's obvious

[junglee_iitk]

Yep, I missed it.

Re:It's obvious

[TD-Linux]

Malicious software running as a user can also exploit existing packages. For a home user it makes sense to trust every signed package in Fedora's main repositories as being secure, especially with frequent updates. You complain about the ability to install packages with security holes, but don't you already put trust in the repositories by using their packages?

I'm also pretty confident that Fedora can patch security holes in their packages faster than you can patch or remove them, or even be notified of them. Even though you are worried about packages not-yet-installed on their server, these are even less sensitive to exploits as the only lag in patches is pushing the package to all the mirrors, and this happens whether or not the user frequently updates their packages.

Re:It's obvious

[644bd346996]

In other words, it allows a remote-exploitable user level flaw to be combined with a local privilege escalation into a remote root exploit. That part isn't particularly new. What is new is that such an attack would take quite some time (to download, install, and start the new software), and would be fully logged along the way. A very small hole indeed. It can be closed by using a private repo that excludes packages with known exploits. Or by not allowing users to install packages containing suid executables. Or by requiring the user to type in their password sudo-style before packages get installed. There are probably several other relatively simple ways to mitigate the small risk.

And none of this changes the fact that if security is this big of a problem to you, you shouldn't be using a distro like Fedora in the first place.

Re:sounds good to me

[petermgreen]

It's a good idea but it's also something that is both unexpected and in many situations undesirable. Therefore IMO it is not something that should be done without warning the person doing the install.

Line crossed..

[Junta]

I undestood locality to console as an 'authentication' scheme for reboot/shutdown -h now. That is a transient state change with, in theory, no lasting effects on the underlying platform. The slight risk of temporary DoS is taken understanding that the user would otherwise resort to ungraceful use of the power button.

I understand the use for removable media, where the owner of auto-plugged media is assigned to the 'console' user. Persistent state change is possible, but restricted in scope to a removable device that someone at a 'console' controlled physically anyway.

However, this is a mechanism that allows a user to make persistent state changes to the 'root' owned content. This is simply not acceptable. The act of installing software is rare enough so the password shouldn't be considered horrible, and no worse alternatives are likely if a user cannot install the software conveniently.

Re:It's obvious

[shutdown -p now]

No, only 80% (which aren't on Vista/7 yet).

Re:sounds good to me

[leenks]

This sounds like a bad idea in a corporate environment, where hot-desking is king. The last thing that corporate support want to deal with is random people completely changing the configuration of the machine so stuff doesn't work right (different versions, slightly different locations / configurations / yadda yadda) for the next user.

Re:It's obvious

[leenks]

If you want to take a trip back in time, by all means. If you want to do anything cutting edge (e.g. linux audio, graphics, video (MythTV etc)) then forget it. And let's not talk about Python.

Re:It's obvious

[smash]

If we're going to compare percentages of Linux users with root, vs percentage of Windows users with admin, i'm betting that the balance will tip towards more linux users having admin on their machine than Windows.

Any half-sane corporate deployment of Windows will not have their users being local admin.

can only end badly...

[smash]

consider that I find an exploitable hole in Package X to get me root.

I can then go to any fedora 12 desktop (say, an entire college lab), and install that package to exploit, to get root.

That is brain damage.

Err I thought this was handled through ConsoleKit

[Nicolas MONNET]

I could be mistaken but I reinstalled F12beta after a major disk crash, and I had to auth once to ConsoleKit, which memorized my authorization for my current user. You don't have to memorize the auth, in which case you have to type the root password each time ... or did I miss something?
I can understand not wanting this for new packages, but for updates to packages already installed, this strikes me as better than the Ubuntu way.
There is one security advantage for the average user, it limits the number of times you have to type the damn password, therefore avoiding the numbing down and making trojan type attacks more noticeable. IE if a fake popup asks your for your root password you might not pay attention if you've been asked a thousand times already for something as mundane as updating.

Re:It's obvious

[shutdown -p now]

All users in "Administrators" group on Vista/7 are not true administrators, but rather more like sudoers in Linux: their accounts don't have sufficient permission to install, so they have to elevate before they do that, but they don't need admin credentials to elevate.

This isn't true of 1) system account named "Administrator" (which is a true admin/root), and 2) Vista/7 with UAC disabled. Even so, I'd expect that most Vista/7 users don't use #1, and don't do #2.

In any case, my 80% figure is not any less accurate than GGP's 99%, and not any less tongue-in-cheek.

PackageKit at fault, not Fedora

[Azureflare]

Lots of posters flying off the handle that obviously didn't read the actual thread. PackageKit added this as a "feature" without notifying the Fedora team. yum still behaves as expected. I'm assuming that PackageKit still requires root to modify shared system areas where the owner is root (e.g. /usr/bin etc.), but users can install their own local packages using PackageKit.

In fact, this is exactly what Mac OS X does by default. I'm not entirely sure if this is really a problem or not. In Linux, users are already able to install local apps into their home directories, this appears to just make it integrate with the UI much easier than before. I remember I had to manage my own user apps in my home directory and it was a real pain, since I had to add that bin directory to my path, and none of those apps appeared in menus anywhere.

Re:PackageKit at fault, not Fedora

[jroysdon]

System - Administration - Add/Remote Software
Games - [x] abe
Apply

Installed abe (Scrolling, platform-jumping, ancient pyramid exploring game) without any password at all on F12 (not user, nor root). It was not installed in the user directory, it was installed the same as if "yum install abe" was executed by root, solving dependencies as well.

I see others discussing how to solve this via polkit. Another solution for my multi-user systems where non-admins shouldn't be mucking around, I see the simple fix as removing PackageKit: rpm --erase gnome-packagekit. If you want to go to the extreme: yum --erase PackageKit.

This also disables notifications of new software releases, but software updates can still be managed with yum and automation could occur with yum-cron.

Re:PackageKit at fault, not Fedora

[Homburg]

PackageKit is developed by Richard Hughes, a RedHat employee. It's not like this is some totally separate upstream that has nothing to do with Fedora.

Re:PackageKit at fault, not Fedora

[Professional Slacker]

I'm assuming that PackageKit still requires root to modify shared system areas where the owner is root (e.g. /usr/bin etc.)

No, that's exactly what people are upset about, that any random account logged in to the physical machine can write to /usr/bin, the things that they can write are limited to the contents of signed packages, but that's still a whole lot more than the absolutely nothing they could write under F11. Also all the comments I've seen are about adding packages, but does this also allow removing packages?

Time to leave Fedora...

[Improv]

I've been using redhat/fedora since at least RedHat5, having previously used Slackware. I thought SELinux was pretty sketchy, but this change is utterly ridiculous. I'm still on FC11, but until and unless they develop some sanity by FC13, I'm going to need to find a new distro (CentOS? Debian? I'm not sure yet)

Re:Time to leave Fedora...

[StuartHankins]

Right there with you. I've been around since Red Hat 5.2, which I purchased.

Re:It's obvious

[Dahamma]

Must have been a while since you last checked ;)

Very few if any network services are enabled/started by default when installed on Fedora. Probably because as you said it is a fairly bad practice...

You dont' need root or sudo to install software

[Dr. Evil]

I was doing it for years on Slackware and it was one of my biggest gripes with package management.

I used to do stuff like download an xmodem protocol app, compile it and run it as a binary from my home directory. There's no reason I shouldn't be able to install OpenOffice in ~/bin/Openoffice instead of /usr/bin/... except that package managers don't work for non-root users.

It is an irony...

[drolli]

that many posters here see this as a security bug "because it enables you to install any exploit found in any package". That is true and untrue at the same time. A good idea would be that no user may create a setuid root binary. But all escalations based on system call implementation errors can be provoked by the user himself by picking out the right code from the source of the packages and compiling it himself using the gcc which is most likely available on many systems.

An even better idea view would be an per-user-view of the computer.

This seems ok

[anexkahn]

As long as it is an option, and turned off by default.....and who has to sign these packages?

Re:It's obvious

[mjschultz]

Honest question: Do RPM files have a way of distinguishing between system- and user-level software? It seems like a fairly obvious thing to have/check, then users could install safe applications (i.e. those that don't have programs in /sbin or /usr/sbin), for their own uses.

Moreover, why can't RPMs just let users install in a private fakeroot directory (like there home directory). That way they don't have to touch the root file system and can easily install packages without needing a password. (Like if I wanted Eclipse, I could just find the RPM and double click to install it, no password, no fuss.)

I think Fedora could make this right if they wanted to.

Re:It's obvious

[Homburg]

Why should the average user have a web or FTP server running on the desktop?

They shouldn't, but PackageKit doesn't allow them to do so - they can install a web server, but they can't run it, or open the ports to allow it to listen on the network.

Re:It's obvious

[sbeckstead]

You just had to bring up Python didn't you. Now you've done it. We'll never hear the end of it now.

Re:It's obvious

[sbeckstead]

Let me teel you a story about a ham. A friend of mine's wife used to cut the lasdt inch and a half off of every ham she cooked. He asked her why she did that. She said, That's what my mother always did. So next time he's at his mothers he asks her why she cut the last inch and a half off the ham. She said, because the pan I had was too small to handle all of it. So just because it's always been done that way doesn't make it a good idea. On the other hand, reasoned change is always better than surprises.

Re:sounds good to me

[turbidostato]

"I allow you to install any package which I have signed. You don't need to log in as a more-powerful user to do so, because I have already pre-approved this action [...] Sounds like a good idea, especially for a corporate environment (single deployment, but if some people need to install Eclipse, they don't need to contact support to do so)"

The proper way to "pre-approve" a package installation in a corporate environment is having it already installed, not raising privileges. If there's a need for a user to work with superuser privileges you give him root password for the box.

"The next step along the line is to tie this into the existing "that command doesn't exist, install Foo to use it", to turn that into "Foo isn't installed, do you want to install it?""

You know Debian allowed this for ages (auto-apt, but of course you need superuser privileges), don't you?

Re:It's obvious

[tepples]

All users in "Administrators" group on Vista/7 are not true administrators, but rather more like sudoers in Linux

If you can elevate, then one should assume you will elevate. I think the idea is that a typical Windows system might have a higher ratio of sudoer to non-sudoer accounts than a typical Linux system.

Re:It's obvious

[shutdown -p now]

If you can elevate, then one should assume you will elevate.

Ah, but there is a subtle difference. The user can elevate, but any random code running under that user's account can't.

To be more specific: any application running under that account can ask to elevate, but that will cause the UAC dialog pop up and prompt the user if he indeed wants to. It's specifically designed in such a way as to prevent any attempt to interact with it in an automatic fashion (i.e. programmatically click buttons on it, etc), so in the end, the user is in control.

If I understand correctly, this is different from what is described in TFA, because there any process running under your account can quietly run RPM and install any signed package from the repository behind your back.

Re:It's obvious

[socsoc]

She could have gotten a larger pan. Or does her oven require RAID 0 and she couldn't get multiple larger pans?

Re:It's obvious

[plasticsquirrel]

The reason unix has always required root access in order to install software isn't because that's the way things should be, it's because there hasn't been another way to make it secure. Now, if you trust the distro's repos, you can safely let users install those signed packages. This is similar to (but more secure than) Mac OS X's policy of letting users install and uninstall but not modify app bundles.

The reason was simply because a user didn't have the privileges to change anything (by default) outside his/her own home directory and the system temporary directory. That is the way it should be -- only changing files that you have permission to change. Allowing users to add or remove software packages in / and /usr is beyond ridiculous. This is why users who want to install software packages themselves, can only install them to their own home directories, so they don't interfere with other users. The only sensible approach is one such as this, where users can only install software where they have permission to do so.

If the Fedora people really want to fix things, they could work on making their packages easy to install into the users' home folders, so users don't have to use the "configure prefix" to change things around, and then compile from source. That sort of user software installation is perfectly reasonable, and completely in line with the overarching concepts of Unix security.

Re:It's obvious

[NeverVotedBush]

Do you really want your users installing and running things like Wireshark and nmap?

Or, maybe compilers so they can turn exploit code into executables all that much easier?

The problem goes way beyond disk space.

Re:It's obvious

[NeverVotedBush]

What about a web server's near cousin - file sharing applications (torrents and such)?

Hopefully you block the ports those use but you don't have to use the stock ports either.

And there are also neat packages that let users do all sorts of fun stuff over port 80 that essentially bypasses firewalls for all sorts of other applications.

If users can now install and run these apps,what shreds of security you had can disappear fast. I don't just care about users being able to escalate privs. I care about new connections to outside servers, home networks, file sharing (and the various legal liabilities and accidental leaving of important information), etc.

Re:sounds good to me

[afidel]

Just remove RH's key and install your own corp key then only sign tested packages. This is actually kind of cool, now you just need an easy way to make package updates mandatory like with published apps in AD.

Re:sounds good to me

[afidel]

What about ongoing maintenance and modular base images? We've had that on Windows since forever where we can publish applications to a user and allow them to install in on first run without requiring administrator access.

Re:Err I thought this was handled through ConsoleK

[Macthorpe]

I believe that they removed the one-time auth and replaced it with no auth whatsoever, hence the brouhaha.

Re:It's obvious

[cppmonkey]

Huh What? OS X let's standard users install software? Sorry but looking at my 10.4 and 10.5 machines that would be a no. Having worked on a few 10.6 machines today I am confident that they are the same but I don't have one here to test. Standard (non admin users) can not "install" software except in their own home directory just like Linux (though installing to one's home directory is not for the faint of heart). Standard users can not add launch deamons or otherwise modify /Library or /Applications. This is actually how it should be. Users can do anything they want in their space so long as it does not affect other users or the system. That's actually security not this we will control what you can and can not do in infinitely fine detail. The big problem is that Linux and Windows require you to modify the SYSTEM in order to do practically anything. Want to run new/updated software then you need to drop some libraries in /usr/lib some resources in /usr/share etc. One of the ways OS X makes management so much easier is to let applications bundle their libraries inside those application bundles. Those same bundles that end users who happen to be the owner in terms of file permissions can indeed modify (unless they are a "managed" user) This enables drag and drop installs and the ability to have ~/Applications/Nifty*.app. So every user can have their own web browser and their own productivity software and it just works.

Packet sniffers, hacking tools...

[marciot]

A lot of people here have pointed out the vulnerability of allowing someone to choose to install a package with a known exploit, but even if no such buggy code existed, there are other vulnerabilities to consider. For example, if regular users install a signed package of wireshark and/or metasploit they can now use such tools to attempt to compromise network security.

Re:Packet sniffers, hacking tools...

[AdamWill]

marciot: regular users have always been able to execute arbitrary code with their own privileges, in any distribution. they just install it to their home directory.

Re:Packet sniffers, hacking tools...

[marciot]

Not so for packet sniffers. Putting the NIC in promiscuous mode requires root privileges. The way wireshark gets around it is by requiring a service to be installed under root that then allows regular users to access the NIC through the service.

Re:Packet sniffers, hacking tools...

[juhaz]

I don't know if what you describe is possible when you install it from sources, or in some other distros, but I do know that the debian/ubuntu and fedora packages of wireshark do no such thing, in them it does NOT work for regular users no matter who installed it.

sudo

[whm]

How does something like this differ practically from using sudo, which in many distros grants the user root privileges without any further authentication necessary?

Re:It's obvious

[PeterBrett]

Trusting the repos has nothing to do with it. If I've got my users on Fedora as their desktops, I don't want them installing packages that I don't know about. Why should the average user have a web or FTP server running on the desktop? Default configurations have frequently been the location for vulnerabilities, and many users could install a service and then not be able to secure it properly because most of those configuration files require root or sudo access.

I agreed with you about this, so I investigated. It turns out that daemons packaged by Fedora are disabled by default, and require someone with root access to enable them. A package won't pass review if that's not the case.

The issue suddenly became much less of a big deal to me. In the end, it comes down to whether you trust the quality of Fedora packages and the security of their signing key. Either you do, in which case this isn't a problem, or you don't, in which case you shouldn't be using Fedora.

Should you trust signed software?

[Loki_666]

My beef with this is a little different i think. While i general i dont like the idea, it goes further than that. I do not trust signed software or web-site certificates. So, just because company X uses a Verisign signature for their security of the website, or in this case signatures are given to software, i still wont trust it just because it has a signature.

This is not paranoia (i hope). Its simply because even security systems are possible to be broken.

Therefore i still would like my security blanket of having to su/sudo to do something that can affect the whole system. A kind of "stop! are you sure?". UAC made a lot of people unhappy, but it was a bold move by MS. I always hated it when applications even back in the days of Win95 would start writing to \Windows\ or \Program Files\

Still, my biggest grief with Windows is the Registry. One file gets corrupt and thats it... bye bye boot up, bye bye many of your licence keys, bye bye everything. Still, this is off-topic, but its a personal peeve of mine, and the day someone proposes something similar for Linux is the day i would switch to BSD.

Re:Should you trust signed software?

[Loki_666]

Damn, why is there no edit button? I wanted to give an example of how things can be faked that are meant to be secure.

Many years ago (student days, in the UK) i recieved some spam (physical mail) but not addressed to me. And this gave me an idea. Back in those days passports were only needed for travel and not much else. For example, to get a bank account you could get away with just presenting two utility bills. So, i decided to start collecting 'evidence' that my name was actually the name from the spam mail. Now it was safe to presume this person actually had lived at my address previously, and therefore some corroborating evidence already existed. I therefore registered myself as a new name to go on the utility bills, got a library card, and got the local council to send me council tax bills in my new name (i claimed that "i" had left this address, and a new tenant had moved in... they never checked with the landlord... after all, somebody was giving them money, and nobody would give them money if they didn't have to. Next up was a bank account. "No, sorry, i dont drive, and i dont have a passport, but i have these two utility bills". Within a couple of months i had a very well documented and valid ID that even the police wouldnt question unless they did some real digging. The only thing i didnt go for was a passport, and this was because a) would have required some real forgery work, and b) probably could have ended up in a lot of trouble.

As an interesting PS, you would not believe how many credit cards i got offered in my new name. I even applied and received one but tempted as i was i never used it and in the end just threw it away to get rid of the temptation.

So... do you think you should trust digital signatures if i can create a fake identity? I'm a lot less clever than some of the people out there.

package conflicts?

[Anonymous Coward]

I don't like this one bit.
What about package conflicts? If 2 packages conflict with each other, a regular user can remove the conflicting package? Doesn't look like a sensible thing to do....
not only can some idiot install random packages from the repo, but also remove certain 'needed' packages.
This is disturbing indeed.

New filesystems

[bytesex]

What you need is a complete filesystem lay-over for the specific user. Then it doesn't matter that a user has installed a certain package. It's just that the other users won't be able to see it.

Re:sounds good to me

[Antique Geekmeister]

Oh, yes, and that model works really well, doesn't it?

Enabling the installation of software is _precisely_ what sudo and controlled access to the "yum" command are for. Leaving this feature on by default is begging for script kiddies to slip their works into other "signed" repositories, such as RPMforge and EPEL and corporate yum repositories. Once I've gotten my GPG key into your system, I can install anything I want.

Fedora 12 is going to be blocked from my internal network until this is fixed. It can be installed in the DMZ, but will be considered an insecure and vulnerable system until then.

Re:sounds good to me

[seeker_1us]

Yes, this sounds like a good way one can use this, but not a reason to have it enabled by default.

Just remove RH's key and install your own corp key then only sign tested packages. This is actually kind of cool, now you just need an easy way to make package updates mandatory like with published apps in AD.

Executive Summary...

[ifknot]

Summary 1/ It's a good idea, really good actually & very useful - YAY 2/ It comes switched on by default which might not be ideal in all situations - BOO 3/ But don't worry, it doesn't leave your machines wide open in any way - YAY 4/ It's one line to switch it off: - DOUBLE YAY pkalalockdown --lockdown org.freedesktop.pakagekit.package-install Conclusion: 4:1 YAY:BOO ratio

Yes, fewer prompts improves security

[Homburg]

Training users to type in their password whenever they need to install software is a usability problem that leads to a security problem of users typing in their password in order to install a trojan with elevated permissions.

Yes, this is a really good point. The most secure system is the one that asks the user least; the more questions you ask them, the less attention they'll pay to them, and so the less security-conscious their responses are likely to be.

Re:It's obvious

[Bazer]

The issue suddenly became much less of a big deal to me. In the end, it comes down to whether you trust the quality of Fedora packages and the security of their signing key. Either you do, in which case this isn't a problem, or you don't, in which case you shouldn't be using Fedora.

Things get complicated when the project's server are physically compromised. I agree that the mechanism is neat and very useful but the developers jumped the gun when they altered the default configuration without notifying anyone. This change wasn't even mentioned in the release notes. That alone raises questions about the project's development process.

Fedora prided itself with default security policy since it had SELinux enabled by default. This change is exactly in the reverse direction.

Re:It's obvious

[PeterBrett]

The issue suddenly became much less of a big deal to me. In the end, it comes down to whether you trust the quality of Fedora packages and the security of their signing key. Either you do, in which case this isn't a problem, or you don't, in which case you shouldn't be using Fedora.

Things get complicated when the project's server are physically compromised. I agree that the mechanism is neat and very useful but the developers jumped the gun when they altered the default configuration without notifying anyone. This change wasn't even mentioned in the release notes. That alone raises questions about the project's development process.

Fedora prided itself with default security policy since it had SELinux enabled by default. This change is exactly in the reverse direction.

In some ways, I think this is a good idea. If users are used to "if I want to install something then I need to enter my/root's password," then they will get desensitised to the necessity of checking that the package is from a trustworthy source.

With Fedora 12's approach, because users will only be prompted for a password for installing unsigned packages, it makes it automatically more notable.

In any case, I agree with you that this is a poorly-thought-out, poorly-documented, and hard-to-locally-revert change. And thus sucks, despite honourable intentions. "The road to hell...," etc.

My favoured approach:

• Installing signed package from repository: prompt for user's password.
• Installing unsigned package/package from source other than repository: prompt for root's password.
• Upgrading signed packages from repository: no prompt.

Re:It's obvious

[Anonymuous Coward]

Want to run new/updated software then you need to drop some libraries in /usr/lib some resources in /usr/share etc.

No. You can install everything you want (libraries, resources) under your home directory. That's what LD_LIBRARY_PATH, the --prefix option to configure, and many other facilities are for.

Even if you're root, you can choose something like /opt or /odd to install anything that doesn't come with the distribution.

Manually poking inside the /usr/lib and dropping random libraries there is about the most stupid and ignorant thing one can do on a linux machine.

Re:It's obvious

[MrMr]

Interesting how everybody who remarks that the Windows default behaviour is copied by this change is moderated troll. Must be a slow day in Redmond.

It's Official...

[nathanh]

... Red Hat is now hiring idiot developers who don't know the first thing about UNIX.

The Linux admins at one of the sites I regularly work were in a furor over this change to Fedora. Within the space of a minute they had concocted a half dozen ways this "feature" could be exploited. This wasn't even taking into account the management and maintenance nightmare of machines where users could install software; they were simply considering the security implications. One of the admins was so furious that he suggested in all seriousness that the site drops Red Hat Enterprise Linux immediately and use SUSE Enterprise. His justification being that if Red Hat can allow this kind of stupidity into their community build, imagine what sort of crap is filtering through into Enterprise Linux. He no longer has any confidence that Red Hat has the faintest clue what constitutes a secure system. I didn't think he was overreacting; this is the dumbest thing I've seen any Linux distribution do, ever.

That the Fedora developers are trying to defend this stupidity is just the icing on the cake. Red Hat should sack every last one of them for incompetence.

Re:It's obvious

[blackest_k]

how come your friend married his sister, isn't that illegal?

If an admin wants to grant a user extra power than thats up to the admin, side stepping the admin by default is retarded.

The big problem is that there are sometimes good reasons not to install the distro version and to install a third party version, (virtualbox springs to mind). There is also the case where a packaged version is broken and a third party version is needed (ubuntu had a situation like that with kompozer).

The iPhone is perhaps the only example outside of this where the distro maintainer gets control of what goes on a system rather than the admin. As the app store is the only place to get approved apps that will run on the iPhone.
Partially its a desire for apple to restrict applications that might conflict with apple and the carriers interests but also the assumption that the typical iPhone user is an idiot who would install any random application which could cause problems on the carriers network. Could quite easily create a porn dialer app for the iphone if it could be installed by the user for example.

An Admin wouldn't want that kind of junk on his lan and really the iphone users are pretty much users on another type of lan (wan).

the way to disable this

[Errtu76]

according to Seth Vidal:

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

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

Re:It's obvious

[KGBear]

Precisely. For some reason though I've been seeing what almost looks like a campaign from users for the right to install software "on their own machines" (never mind these machines belong to the company, not them). This is being billed to management as an absolute necessity in order for people to be able to get work done. Windows is being used as an example by Linux users, who want something akin to the "power user" group Windows offers. I've spent hours this week explaining to managers why giving users full sudo is exactly the same thing as giving them the root password. The fact that Fedora comes up with this new "feature" precisely now raises flags all over my paranoid brain. I'm absolutely certain before the week is over some manager will suggest replacing all our Ubuntu workstations with Fedora as a way to solve the "problem" of users not being able to install software. This looks suspiciously similar to the way Windows took over the corporate desktop in the early-to-mid nineties.

On a related note, what happens in settings like computer labs, where users can be students in a school or patrons in a library, etc.?

Re:It's obvious

[nathanh]

This isn't necessarily insecure.

Yes, it is most definitely insecure. This change in Fedora 12 allows an unprivileged user to:

• Start and stop network services
• Install setuid binaries
• Remove and install files owned by root
• Modify system configurations
• Change user and group databases

On any normal system, the unprivileged users can do some of these things only through a *very* small subset of programs (e.g. passwd) that have been heavily vetted, and even then they still have an occasional exploit.

Now Fedora is saying "hey, all 15000 of our programs can do all of these things, and any unprivileged user can install any of the 15000 programs". Fedora has increased the number of potential exploits by several orders of magnitude.

That's insecure.

Whew

[kernelpannik]

I'm just glad Fedora got this mistake out of the way already. If this is truly a default setting in upstream PackageKit then the next LTS of Ubuntu might have suffered the same mistake. With all this stink, however, I imagine it will not be duplicated in other distros.

Re:It's obvious

[Hognoxious]

To be fair it isn't intended to be bleeding edge, and it's more biased towards use on a server. I found it OK for installing SAP on (RHEL is officially supported and Centos is compatible with it).

But it's true that the default multimedia support is almost nonexistent. Totem, for one, is a joke. Whether this is down to political issues around freedom I don't know.

Re:sounds good to me

[afidel]

How are you going to slip something into a signed package?!? That's the whole point in signing it, it can't be tampered with or the signature becomes invalid.

Re:It's obvious

[Martin Blank]

I may also have an issue with my users installing a dev environment. If they can do that, what's to stop them from bringing in or downloading code that they can compile which then takes advantage of unpatched vulnerabilities?

Even a program that seems innocuous, like IM, may be a problem if there's a policy against using IM in the workplace.

Pourquoi sans English

[Benson Arizona]

Has anyone else noticed French words such as sans gradually creeping into English in place of perfectly good words such as without? I believe that this is not coincidental but rather the work of a dedicated group of French extremists who, by gradually increasing the proportion of French words in circulation, hope to replace the English language entirely within just a few decades. Par recognizer this behaviour, we can arret it before it gets out of main. Mai, si nous do not faites attention then pendant just a few ans, we could find qui French is the nouvel Anglais. Dit "non" maintenant a English avec Francais!

Diese Anmerkung ist auch auf Deutsch vorhanden.

Well it's lunch time and all the blinkenlights are working...

Re:sounds good to me

[Antique Geekmeister]

You sign the package, yourself, with a stolen key. Since a local site repository may have far less security than a major repository like RedHat, and even RedHat has been compromised in the past (http://blog.internetnews.com/skerner/2009/03/red-hat-fedora-reveals-details.html), simply installing packages for any random user should not be permitted. In particular, the ability to install out-of-date, previously compromised, but previously signed packages without administrative privileges should be blocked.

Re:It's obvious

[Martin Blank]

It turns out that daemons packaged by Fedora are disabled by default, and require someone with root access to enable them. A package won't pass review if that's not the case.

As I mention in another post, there is a wide variety of packages that could be installed which make me uncomfortable. It's good that they can't install daemons, but what about dev environments? IM programs? Games? Workplace policies may prohibit the latter two, and dev environments bring about their own issues that I probably don't need to go into.

Dancing bunnies

[tepples]

The user can elevate, but any random code running under that user's account can't.

Unless the "any random code" is a Trojan horse that promises dancing bunnies if the user installs it.

It's specifically designed in such a way as to prevent any attempt to interact with it in an automatic fashion

Another Trojan horse program would be disguised as an accessibility tool to make it easier for users with disabilities to interact with the computer.

Re:Dancing bunnies

[shutdown -p now]

Yes, of course. There's nothing you can really do about the "dancing bunnies" problem - if a user must be able to do something, you have to give him some way to access that feature, and at that point, no matter how many prompts there will be, the security is only as strong as hard it is to convince the user. And users generally need to install software.

In any case, this area is the same for all OSes/distros being compared, so we can ignore it and focus on the part about which the OS/distro can actually do something.

Re:Dancing bunnies

[tepples]

And users generally need to install software.

Game consoles and some mobile phones manage to work around this: they just refuse to allow installation of unsigned software altogether.

• Sony and Nintendo implement a signed-only policy the wrong way: allow only a corporation with a dedicated office, whose software has previously been published on another company's platform, to develop.
• Apple and Microsoft do it right: allow anyone to get started developing and self-publishing for the price of a computer, the device, and a developer certificate that's cheap even if you get only a couple donations a month from users.
• Linux distributions that use apt or yum do it similarly by default: allow installation from repositories vetted by the distro publisher, with inclusion standards based on quality and licensing guidelines as opposed to organization size. The "hole" in this scheme comes once the administrator takes the step of manually adding other repositories or sudo apt-get install build-essential.

Re:Dancing bunnies

[shutdown -p now]

Apple and Microsoft do it right: allow anyone to get started developing and self-publishing for the price of a computer, the device, and a developer certificate that's cheap even if you get only a couple donations a month from users.

Nothing stops malware developer from purchasing a certificate and signing his malware with it. The only way to work around this is to not just restrict installation to signed packages, but to packages from a repository controlled by a single trusted entity (e.g. App Store). Apple does that, MS does not. But in any case, this model has many obvious flaws of its own, and severely restricts user's freedom. I, for one, will never own any phone on which I cannot install any application that I like, from any source.

Linux distributions that use apt or yum do it similarly by default: allow installation from repositories vetted by the distro publisher

Not all of them. E.g. Ubuntu allows the default user account to edit repositories (it can sudo, which is effectively equivalent to a "Are you sure you want to?" prompt). So it is still possible to convince the user to edit repositories, and then install the application, to see "dancing bunnies".

Furthermore, all distros I know of that use apt/yum also let you use dpkg/rpm directly; so, again, if user can elevate to use those, he can in theory be convinced to do so.

Re:It's obvious

[nmx]

If the patient REALLY wants that head CT, even though it's unnecessary and expensive, what about that one in a million chance that there was really a problem that the doctor missed that the test would have caught? Can you say lawsuit? Over-medicating and over-testing are a big problem, but don't blame the doctors, blame the lawyers and the misguided notion among the public that more treatment is always better.

RTFA

[fulldecent]

Read the first link. There's about 1000 people basically arguing that "if any one Fedora-signed package is compromised, then all default-install systems can be compromised by unprivileged users."

Then read comments by Richard Hughes.

It's like having an argument with someone who believes in god.

Want to see a fun security fail in Linux?

[drinkypoo]

Step 1: Install Ubuntu Karmic
Step 2: Log in as admin
Step 3: Create an unprivileged user
Step 4: Use user switching and log in the unprivileged user
Step 5: Log out this user and enjoy being switched back to your admin user's desktop automatically.

Now, to be fair, this is an upgrade from Jaunty, which I think may have even been intrepid before that. So perhaps this wouldn't happen in a fresh install. I currently have the problem though.

We can have this!

[ClosedSource]

If they allow Linux users to install packages easily, the next thing you know everybody will be using Linux.

UNG?

[ClosedSource]

"... Red Hat is now hiring idiot developers who don't know the first thing about UNIX."

Of course some Linux knowledge might be helpful too.

It's a herd thing

[ClosedSource]

"Yes, because as everyone knows, whenever ANYONE speaks about Linux, it's the SAME person who made another previous statement about Linux."

No, but they're often thinking the same thing.

Re:It's a herd thing

[natehoy]

"Mooooo"

Oh, sorry, I pronounced that wrong.

"Gnuuuuuu..." :)

Re:It's obvious

[psmears]

I may also have an issue with my users installing a dev environment. If they can do that, what's to stop them from bringing in or downloading code that they can compile which then takes advantage of unpatched vulnerabilities?

If they can bring in or download code in source form, what's to stop them bringing it in or downloading it in binary form? While I agree that there are aspects of the new Fedora policy that are questionable from a security point of view, preventing users from installing a development environment isn't one of them, since it doesn't buy any security at all...

Re:It's obvious

[Martin Blank]

Web and mail filters where I work catch a good portion of the malicious binaries out there. However, they do not recognize source code. I can block users from connecting their flash drives, and I can block those malicious binaries (or a large portion of them, anyway), but the source code is a much more difficult thing to block.

You're a good sport

[ClosedSource]

What are you doing around here?

Re:It's obvious

[sbeckstead]

Whooooosh!

Re:It's obvious

[sbeckstead]

If an admin wants to grant a user extra power than thats up to the admin
extra power than what? Oh and "thats" isn't a word.

Re:It's obvious

[sbeckstead]

how come your friend married his sister, isn't that illegal?
Yeah it was supposed to be Mother in law's house.

Re:sounds good to me

[pembo13]

Well, an enterprise can choose to enable allowing installation sans password of signed packages... not necessary to be a default.

And the command not found tie in is already available in F12

Re:sounds good to me

[turbidostato]

"We've had that on Windows since forever where we can publish applications to a user and allow them to install in on first run without requiring administrator access."

That's because Windows need it due to two historic circumnstances:
1) Lack of tools for properly remotely manage systems (so basically the "install on first run" was a way for the IT guy not having to go physically to the user's system to install it). That's not the case anymore
2) The registry which makes that a simple software installation requering local tweaking on the binary blob called registry

On environments that
1) Are properly and easily remotelly managed
2) Doesn't need to pollute the local system in order to run a program
you don't need that (NFS and the automounter is all you need to allow users "to install the program on first use" on UNIX and Unix-like systems on a corporate environment).

Re:sounds good to me

[afidel]

Cool, NFS and automount works great for a workstation or server with a very fast LAN connection to the NFS server, now how do you provide that same service to a road warrior?

Re:sounds good to me

[turbidostato]

"How are you going to slip something into a signed package?!? That's the whole point in signing it, it can't be tampered with or the signature becomes invalid."

But what do you exactly sign?

All you sign is that a certain piece of code is the very untampered one a given provider did release. Does signature provides a "fit for usage" meaning? Does it provide a "for your eyes only" security?

The most simple case: Take a DHCP daemon properly signed by Red Hat or even by your local authority. That's the real code, pristine and untampered just as the very signing process is meant to procure. Now, what happens when two or more instances of that very blessed piece of code happen to run out of control in the same network segment?

Re:sounds good to me

[turbidostato]

"Cool, NFS and automount works great for a workstation or server with a very fast LAN connection to the NFS server, now how do you provide that same service to a road warrior?"

AFS or gasp! a corporate laptop with all corporate sofware already installed.

Dependencies

[unixguy43]

Like many of the posters so far, I don't like users having the ability to install packages either. While there's exceptions, "users" are generally people who don't have the skills to do the administrative tasks on the system. If they have the skills, then they should have root (or sudo) access, plain and simple. Why? Dependencies. Virtually anything that someone would want to install has dependencies. Admins know about dependencies, and understand the risks associated with making changes to them. So Joe User grabs the latest and greatest music app and wants it installed, so he installs it- along with it's 3 dependencies, one of which complains that library ld.so.1 will be replaced and is needed by some other installed program. Joe User just wants his music player, so he overrides the install and forces it to overwrite the library and redirect the related links to the new library. One or more apps are now cratered because of a failed dependency. The admin now has to go through and rectify a library that was there at one point, but is now gone because of a user. Anything that has potential to change the functionality of the system should not be in the hands of a non-privileged user.

Important: policy will be changed

[AdamWill]

Important note: the policy in question will be changed, likely with an update to be issued tomorrow. The new policy will be more restrictive than that in Fedora 11 (it will require root authentication for each package installation operation). Please see the official announcement and the more extensive fedora-devel-list post for more details. Thanks.

Re:sounds good to me

[Homerz]

This is a good thing.

Really?
Consider the consequences of this happening ... again:

Last week we discovered that some Fedora servers were illegally accessed. The intrusion into the servers was quickly discovered, and the servers were taken offline.
...
One of the compromised Fedora servers was a system used for signing Fedora packages. However, based on our efforts, we have high confidence that the intruder was not able to capture the passphrase used to secure the Fedora package signing key.

Now imagine an admin had performed a dist-style upgrade from Fedora 11 to 12 (install the F12 "release" RPM, then "yum update"), without knowing about this default change to his systems' security, because it would never have occurred to him that Fedora/RH could make such an incredible policy decision. A few days later the Fedora/RH servers are hacked (again), but this time they're not so lucky. Meanwhile, user "blogs" on the admin's network is told (by PackageKit) there are important security updates available, so he decides (without any malice) to go ahead and apply the updates. Thanks to this new "security" policy, he is able to do so, but unknown to him, he's just rooted the system, thanks to the injection of a modified (and re-signed) malicious package on the hacked Fedora/RH server. This malicious package begins by deactivating SELinux (root privileges), then proceeds to delivering it's malware payload across the entire system, and (depending on what's visible to the host) the rest of the network (perhaps also by E-mail).

Now you might think this would have happened anyway, even if it had been the admin who'd performed the update, but there are a few important differences:

• The system(s) are supposed to be the admin's responsibility. This is a crucial point, even in a "home" network. Someone has to be delegated to take responsibility for the system(s), because otherwise the result is conflict and chaos. So if the admin screws up, then he only has himself to blame, and users who screw up, should not affect any other account, or the system at large
• The admin has the ability to perform full system backups prior to deploying updates, so if things go wrong, then he has the ability to put them right. Users with selectively elevated privileges do not, and this is a potentially fatal combination
• There needs to a clear separation of privileged from unprivileged access on a computer system, so that incident like the above don't happen. User "root" doesn't run X11, doesn't run a Web browser, doesn't play games, in fact doesn't do anything other than essential maintenance, and thus is not susceptible to certain attack vectors like social engineering. Unprivileged users are, but this doesn't matter because they are (or should be) unable to make any system-wide changes

Even on a single-user system, Fedora's new Windows-style (in)security policy is dangerous, counter-productive, and frankly insane.

This is definitely not a good thing.

Re:It's obvious

[blackest_k]

Actually I'd heard this story before, years ago. It kind of bugs me when things are presented as original when I know they are not.

(from google)
Results 1 - 10 of about 663,000 for cut off end of ham because that's what mother did.

Sometimes i make mistakes in grammar too.

Re:It's obvious

[sbeckstead]

Yeah it's called a parable and it's always told that way. I really did hear it for the first time from a friend about 32 years ago.