Just a quick note, if you don’t like Fedora 12’s policy, you probably don’t understand how systems today currently work.
This is much more secure, and you are able to disable it. If you are using systems in public, then there is much more you need to disable such as removable media automounting etc, and would not use default settings anyway.
The current way of throwing blanket root access out for any system change is inherently less secure, their change aims to only allow signed package and that 1 specific action to occur.
Yes you could make a collision, but if you can’t trust your package sources, you can’t trust your system as a whole, so the entire idea is moot.
Related posts:
- Stimulus package I have been, in my short political life, generally a...
- Fedora 11 vs. Ubuntu 9.04 Put Fedora 11 on my laptop just out of boredom,...
- 5 Things I Have Learned About Corporations When I was younger I would email successful people and...
#1 by nxvl on November 19, 2009 - 1:16 pm
Quote
Well, actually is not a thing of trust to the archive or not the problem is this: https://bugzilla.redhat.com/show_bug.cgi?id=534047#c65
and that malware will be able to basically “install everything” which will take over your hard drive without you knowing about it
#2 by Ante on November 19, 2009 - 4:59 pm
Quote
Er… It’s not that you don’t trust, but bad things do happen. For example, not so long ago, RH servers were hacked and ssh packages were compromized. Now imagine someone does that with packageXY – and then gets users to install that package. Lots of bots, right?
Another thing to watch out for. Bugs do happen. Image packageAB has a bug that enables privilege escalation. As sysadmin, you can opt to deinstall or not install that package at all. But you can’t do anything if user installs that package. He can then use that bug and get her self root access to machine.
If it’s such a good idea, why do they add big red warning in release notes? http://docs.fedoraproject.org/release-notes/f12/en-US/html/sect-Release_Notes-Security.html
#3 by sharms on November 19, 2009 - 5:19 pm
Quote
If the master package key is compromised, then your whole system needs to be rechecked, this is totally mutually exclusive and does not make the problem worse or better.
#4 by Ante on November 19, 2009 - 5:40 pm
Quote
You missed the part ‘bug in thousands of signed packages’. You don’t need compromised signing key (and compromised keys already happened to RedHat, and Debian/Ubuntu had repetitive ssh keys). You need one bug. Bugs happen all the time.
#5 by Julian Aloofi on November 19, 2009 - 6:12 pm
Quote
Modern system or not, this is absolutely not acceptable to be enabled by default.
It’s not that I don’t trust Fedora as a package source. I absolutely do. And this problem is not at all about package sources. Imagine you have a multi-user system.
Everyone can install software? Not a good idea!
Imagine you set up a system as administrator. Any user can install software? Not a good idea!
It’s not about Malware. Software can have bugs, software can change the way your system works, and not all people have unlimited disk space (although that is not a problem these days).
This just changes the way a Linux system worked ever since (don’t know about UNIX in general).
I see, users have to be logged in at a local console. But you never want users to install software, unless you explicitely gave them permission to do so. Even Windows got this now.
And if it really is intended to help new users, why do you still have to enter your password in the packagekit GUI app? How likely is it that new users will use the terminal application? The arguments given by the PolicyKit maintainer don’t make sense.
#6 by Jeffrey Stedfast on November 19, 2009 - 6:16 pm
Quote
Ante: If some hacker roots the RH servers and users install the compromised packages, then the package install policy is irrelevant.
Secondly, as far as bugs in software, yes, they do happen all of the time – but how often can these bugs cause privilege escalation? That can only happen if the software is setuid or setguid and there are very few of those (most of which are probably already installed as part of the base system anyway).
Thirdly, this policy change was ONLY done for the Desktop spin (not the workstation spin, not the server spin, etc) and ONLY for local users (i.e. they have physical access to the machine). Remotely logged-in users are not allowed to install software w/o a password.
Once a user has physical access to the machine, this policy is a minimal threat compared to the user’s ability to boot off a floppy/cd (which would give him easy root privs) or a whole slew of other attack vectors that are far easier to take advantage of.
To reiterate, the Desktop Spin is not meant for use on public access machines (such as you might find at the office or at the library or a computer lab, etc), it is meant for home PCs. Home PC users do not lock down their systems from local access because it is pointless.
#7 by Jeffrey Stedfast on November 19, 2009 - 6:19 pm
Quote
Julian: you totally misunderstand the situation. This change was ONLY made for the Desktop Spin which is not meant for multi-user systems or systems where there would be a SysAdmin (if there is a SysAdmin, then you should be using the Workstation Spin, not the Desktop Spin).
#8 by Julian Aloofi on November 20, 2009 - 8:30 am
Quote
Jeffrey: Well, I’d install the desktop spin on a multiuser system with a GUI, because there is no Workstation Spin
I have not checked the behaviour when installed from the install DVD, but I guess it’s just the same.
#9 by Jeffrey Stedfast on November 20, 2009 - 8:42 am
Quote
Julian: Well, if you install the Desktop Spin on multiuser systems, there’s a lot of other things you’d also have to lock down. Again, the packagekit thing would be the least of your worries.