Major Security Hole In Samsung Linux Drivers 295
GerbilSoft writes with news of a major security hole in Samsung's proprietary Linux printer drivers. From the Ubuntu Forums: "Just to inform you about a recent post on the French Ubuntu forum about Samsung drivers (sorry, in French). [Google translation here.] It appears that Samsung unified drivers change rights on some parts of the system: After installing the drivers, applications may launch using root rights, without asking any password. What is more, you may be able to kill your system, by deleting system components, generally modifiable only by using sudo." GerbilSoft adds: "Among the programs that it sets as setuid-root are OpenOffice, xsane, and xscanimage."
Re:suid is evil! (Score:2, Interesting)
Install applications as root (Score:5, Interesting)
Re:Windows coders (Score:2, Interesting)
Your point is, Linux is good because only select people use it for select few apps. That's why Mac is good as well.
I suppose this is an example of a self-defeating prophecy: it's secure/stable, so use it! But if many use it, it's no longer secure/stable.
Re:Install applications as root (Score:5, Interesting)
This works OK for a multiuser system. If you run systems with 100 users on each and one gets their home directory hosed, you restore from backups and problem solved. Everybody else continues having uninterrupted service meanwhile.
But on a personal box everything of importance is in $HOME anyway.
What is needed is something like SELinux, which makes it impossible for applications to do things they shouldn't be doing.
I say "something like" because SELinux is a very complicated system and AFAIK still badly documented. But it sounds like a step in the right direction.
Re:Windows coders (Score:5, Interesting)
As the PC developed, IO calls were to be linked through the BIOS. The idea was that each device was to have a ROM that linked itself to the system's BIOS and that there would be a more unified system for handling I/O. Well, for most people, BIOS wasn't fast enough so people started writing code to work around it. And that's where the PC's "bad programming habits" began and it just got worse from there.
Now, instead of people using the Windows API properly, people are using undocumented APIs that are subject to undocumented change, people are still trying to squeeze more performance from their apps by moving code into ring-0 virtual driver code. If you don't already know, "ring-0" means the code has access to the entire machine and all memory. And when apps misbehave, they are flying without a net since the ring-1 and above offer levels of "protection" from misbehaving or malfunctioning apps.
This culture of performance over stability and proper coding methods has undermined the security and stability of Windows. I'm not going to assert whether or not Microsoft is partly to blame or has any blame in this. But I will say that Windows coders have bad habits that are quite common and prevalent.
As Linux coders grow in numbers, it is more and more important that things like abusing root or setting up kernel modules unnecessarily should be protested and prevented at every turn. To not fight it could result in the same problems and reputation that Windows now enjoys.
Re:Install applications as root (Score:4, Interesting)
It also messes with the lpr command (Score:2, Interesting)
You can remove all of the SUID crap and point
Keep in mind that the printer driver's control panel and other stuff that Samsung installs is also SUID. The SUID garbage happens even when installing a regular printer without the scanning capabilities.
I like that they at least tried to write a Linux driver, which is many steps further than a lot of companies, but it does need to stop stomping all over the system like a Windows application would.
Re:Flawed Design... (Score:3, Interesting)
The GGP post was citing the scanner situation as evidence for the "flaw of the superuser". The GP post explained why that evidence is not applicable, as it is solvable with standard practices of any well-managed distro. There is little point in saying that "groups don't fix the flaw of a superuser", since the GP explained exactly how groups *do* fix at least part of that "flaw".
Personally, I think that standard Unix security model is complicated enough as it is without using ACLs. Not to say that ACLs aren't elegant and neat sometimes, but in *real world use* the problems they are supposed to fix are handled in a fuller and more comprehensive way by running an insulating control daemon, virtualization, etc. If you want a secure, locked-down box, you don't allow direct unprivileged user access to it anyway, running public-facing daemons in chroot. If you want a multi-tenant general-purpose server, there are plenty of options for light, fast virtualization and process containment (same old chroot, even) - otherwise users can muck up enough things even with strict ACLs through DDOS, etc. If you are running a personal computer, the standard "god mode versus user mode" security model is more than enough - it is simply easier to be prepared for a wipe and reinstall, which ends up being necessary even with ACLs due to general ways how our desktop computers accumulate cruft.
ACLs are an attempt to tack on semantics onto files - which is better handled in application code, instead of complicating general-purpose code. Simply a university-borne solution to a problem that should be obviated with other tools in the first place.
Re:Lazy Design... (Score:5, Interesting)
I don't see any reason to think something malicious of it, but I think this goes beyond stupidity. It's not quite as bad as distributing rootkits with your CDs, but I think it's getting there.
What's the purpose of this [expletive deleted]? (Score:3, Interesting)
OK, I read this message, and I can't understand why on earth any software would need to, even temporarily, set the setuid bit on anyone else's software. What's the purpose of this action?
Re:Flawed Design... (Score:3, Interesting)
That's why the inventors of Unix took it back out again when they did their next OS [bell-labs.com]
btw. it's dependent
Re:Flawed Design... (Score:3, Interesting)
Which is why most distros support POSIX ACLs...they are just not widely used. Ext2, Ext3, JFS, XFS, and ReiserFS all support ACLs (extended attributes). I believe NFS version 3 and 4 also support ACLs. why most distros support POSIX ACLs...they are just not widely used. Ext2, Ext3, JFS, XFS, and ReiserFS all support ACLs (extended attributes). I believe NFS version 3 and 4 also support ACLs.
True, but until most GNU/Linux applications fully support ACLs, I highly recommend not using them and sticking with controlling access through Groups instead. Similar results to ACLs can eaily be obtained through groups by changing the umask of your users to 002, creating a directory to share, change the group ownership, then make it writable and setgid (chmod g+ws) for the group.
Re:Windows coders (Score:4, Interesting)
1. It has been shown that the signature can and has been forged
2. Unsigned drivers are still installable with only a warning given to the user at install time and the user has little to no choice but to install the unsigned driver if they wish to make use of whatever it is they are using.
the only benefit is "user awareness" and the effectiveness this may yield will vary by the quality of the user... and we more or less know what that leads to.
As far as your assertion that Linux can't do that? I'll leave that alone for now... you're about to be flooded with a number of other responses that are likely to be worded better than I ever could. But to be short, Linux can't "sign" drivers. Instead driver modules are to be compiled to match the specific kernel and will refuse with NO option by the user to over-ride that decision. So in a way, it's actually more secure. (This excludes the existence of DKMS or dynamic kernel module support which, if the user installs it, can neatly override this particular behavior from the kernel in a way but the kernel module/driver itself needs to be created within the framework of DKMS itself and all manner of other complications...so....)