Major Security Hole In Samsung Linux Drivers

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

Comments

Lazy Design...

[Azuma Hazuki]

This sounds like a cheap hack. There is no need for these things to be setuid root, not on the program level. Sounds like someone is used to programming Windows drivers...

I'm tempted to infer something sinister about this, but then I remember the old adage "never attribute to malice what can be explained by stupidity." It keeps your blood pressure nice and low.

Re:Lazy Design...

[jimpop]

Bingo. Someone should be fired at Samsung, specifically the manager who hired the programmer with out vetting their capabilities.

Re:Lazy Design...

[jkrise]

My thoughts exactly. Although, given Slashdot's tendency to sensationalise things (remember the JRE bug that could make everything vulnerable?) it could be a while before we can get to the truth of the matter.

The key qn. is:

Were these programs given elevated privileges in order for the Samsung device to work?
OR
The driver elevated privileges of programs unrelated to it's functioning.

If the latter is true, then Samsung needs to be conngratulated for highlighting the pitfalls of closed source drivers in Linux.

Re:Lazy Design...

[EveryNickIsTaken]

Sounds like someone is used to programming Windows drivers... No, it merely confirms that there are lazy programmers creating crap code for all OSes, including Linux.

Re:Lazy Design...

[B'Trey]

I can't tell you why the driver did what it did. However, from what I've read, the driver actually moves binaries to new locations and replaces them with a startup script which is set to run suid. That's way, way, way over the line. It breaks lots of stuff, like updates and patches. Someone doesn't deserver to be fired. Someone deserves to be tarred and feathered and banned from ever touching a computer again.

Re:Lazy Design...

[CastrTroy]

The employee should be fired. They are the one who actually made the mistake, and who has shown they have no abilities. Managers shouldn't have to take the all the blame for their employees mistakes. If the manager has had a bad track record and this kind of thing happens too often, then maybe he should get fired, but you can't make the judgement that the manager should get fired every time an employee screws up.

Re:Lazy Design...

[quanticle]

In my opinion, the manager is responsible for the conduct of the employees. Taking responsibility for those working under you is a fundamental part of good leadership. Its the manager's job to check the employee's work to make sure that it meets quality criteria. In this case the manager failed in his or her supervisory duties.

Re:Lazy Design...

[und0]

To me seems a programmer with windos habit:

- "Hey, i need to access the printer device, what's the admin equivalent on this lunix stuff?"
- "Err, using root maybe?"
- "Thanks!"...

Re:Lazy Design...

[MrNaz]

You're obviously not in management.

Re:Lazy Design...

[init100]

In my opinion, the manager is responsible for the conduct of the employees. Taking responsibility for those working under you is a fundamental part of good leadership.

I agree. The higher responsibilities of managers are part of the reason for their higher salary.

Re:Lazy Design...

[Anonymous Coward]

When I tried to install the Samsung drivers, they ruined my Slackware system. They started at "/" and stripped read, write and execute permissions of EVERY FILE AND DIRECTORY IN THE SYSTEM.

You could use it if you were root, but otherwise you were hosed.

Then I discovered the "Splix" Linux drivers for Samsung printers. Those worked rather well without using anything from Samsung.

When I switched to Fedora, I found out that all you had to do was select the Samsung 2250 as your printer under print manager (my printer is a 2510), choose the usb: printer location, and you were golden. I'm using the foomatic, I think, but Splix is available as well.

Why would you use a proprietary driver when support is already built in? Meh... It's not like Samsung's software's any good anyway. All it does is offer you a "Buy more stuff now" button and nag you when your toner's low.

Re:Lazy Design...

[somersault]

What's the other part?

Re:Lazy Design...

[a.d.trick]

I think lazy is pretty generous. Putting setuid root on something as powerful as openoffice is flat-out retarded, period. These guys are driver writers, they should know better than this. I mean they, really ought to know better than this. It would be like Red hat dumping ssh and recommending telnet for remote shell access and transfer of sensitive information.

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.

Re:Lazy Design...

[DrSkwid]

That's bollocks though.

Higher wages for promoted people is to make the lower paid workers work hard so that they might get promoted.

It's not a reward, it's a stick.

Re:Lazy Design...

[Liquidrage]

A potential flaw in a linux driver from Samsung is blamed on MS, in 2 different manners no less, and it jets to +5.

Classic /.

Re:Lazy Design...

[Anonymous Coward]

I'm tempted to infer something sinister about this, but then I remember the old adage "never attribute to malice what can be explained by stupidity." It keeps your blood pressure nice and low.

No it doesn't: I tried that but now I just get angry several times a day at how unutterably stupid everyone is.

Re:Lazy Design...

[rgravina]

isn't it a carrot?

Re:Lazy Design...

[kungfoolouie]

Agreed. That is why CUPS runs as root and your app that needs to print does not have to. Way to go Samsung. How about not outsourcing your driver development to folks that have never developed on said platform?

Re:Lazy Design...

[guruevi]

Luckily I just bought a 'virtually indestructible keyboard' which can handle the fluid I just squirted all over it.

I am an employee and I do have a manager, I've had lots of them. My manager's job is to approve the reports for my hours performed (although he seemed to have given that job to the lead sysadmin) and the occasional expense report. My managers usually don't even understand or try to understand what I am doing, let alone check the quality of my work. They usually don't even know what many of the terms, abbreviations and lingo means that I am using when I propose a solution. All they do is wanting to change something after everything is working.

Don't give your manager too much credit, he usually does have a lower IQ and technical knowledge than you. They only know how to suck up to their bosses to get further up, that seems to work though, good quality work is secondary or even tertiary (2nd is not bothering the bosses too much or spending too much). Quality is actually for the QA department which seems to be in place only to bother you when the CUSTOMER complains of something that is lower quality.

Although I have to say my current manager is very good at not bothering me or being stupid nor annoying, I still think that they do not care very much about what I am doing, as long as everything keeps running and work gets done reasonably in time.

Re:Lazy Design...

[Obsid]

Even on this way, I still don't understand why a program that exploits something that is plugged on USB or the parallel port should have to run as root. On my system, cupsd runs as "cupsys".

Re:Lazy Design...

[Obsid]

It's not blamed on MS and in fact, I haven't seen the name of the company quoted in comments before yours. This is not so frequent ... This time, we have real reasons to believe that this package has been created by Windows users. Just take a look to the installation page on their website: the Winzip icon in front of the .tar.gz link, the section name within square brackets, the ./autorun program that should be run by the user, and so on ...

http://www.samsung.com/uk/support/productsupport/d ownload/FileView.aspx?cttfileid=828690&type=Print+ Solutions&typecode=&subtype=Multi+Function+Product s&subtypecode=&cmssubtypecode=&model=SCX-4200&file type=DR&language=&LSSI=/uk/module/ssi/left/lmenu_p rintsolutions_multifunctionproducts.sec&RSSI=/uk/m odule/ssi/right/rmenu_printsolutions.sec

Some passages are delicious:

2. When the Administrator Login window appears, type in root in the Login field and enter the system password. 3. Download and extract the driver [root@localhost root]#tar xzf [Downloaded File Name(XXXX.tar.gz)]

The "Administrator Login" window. Fun. They also want to open a graphical root session, then download the file from here. However, the user still have to understand by himself that he has to open a console, go into the right directory and type the command written after the # .

Rookies.

Re:Lazy Design...

[Liquidrage]

Notice how my post was a "reply" to another post.
You might want to start there before saying things like "It's not blamed on MS" and "I haven't seen the name of the company quoted in comments before yours".

Pssst...rookies

Re:Lazy Design...

[HiThere]

Some manager should...but probably the HR manager rather than an IT manager.

OK, it's unfair to fire the HR manager because he can't judge programming skills...but by that same criteria he shouldn't be able to pass on hiring programmers. If he gets the power, he should get the blame.

It will be interesting to see how quickly Samsung fixes this blunder. THAT'S how one should judge the company...this time.

Re:Lazy Design...

[mvdwege]

On my system, cupsd runs as "cupsys".

Nope, it doesn't. It must run as root, in order to bind to its port, which is in the privileged range. However, as per Unix Best Current Practices, it drops root after binding to the port.

Mart

Re:Lazy Design...

[jimpop]

The real underlying problem is that BAD management promotes and contributes to furthering BAD management. Once BAD management sets in it is difficult to cure. After all it was a BAD manager who enabled the situation to begin with... and what BAD manager is going to fix their own BAD work? Well managed companies fit into two categories: 1) small and family oriented or 2) have high turnover rates.

Re:Lazy Design...

[Raenex]

You might want to think more critically and re-read that post you replied to. "Windows" is mentioned, not Microsoft. "Sounds like someone is used to programming Windows drivers" [emphasis mine].

And indeed, Obsid's reply to yours backs up that assertion with a lot of evidence, where the "someone" would be Samsung.

Re:Lazy Design...

[Liquidrage]

Last I knew Windows was made by MS. And the other part of the conspiracy theory he mentions he won't mention is also MS.
Just stop. You'd have to try and break it down into a semantical arguement to have a point. At which case you're adding nothing to the discussion.

Re:Lazy Design...

[sakasune]

Luckily I just bought a 'virtually indestructible keyboard' which can handle the fluid I just squirted all over it. What have we told you about sharing information like that....

Re:Lazy Design...

[init100]

Possibly none directly associated with the actual managing, I was thinking that managers are usually older, with greater experience and larger contact network, which also contributes to their salary.

Re:Lazy Design...

[somersault]

There wasn't any budget left for carrots.

Re:Lazy Design...

[fuliginous]

Sounds like they hired someone who doesn't know how it should be done and so did it the only way they could work out (quickly) to do it.

How come an app can do that?

[forgoil]

It seems extremely dangerous that a user can install something like that, with that kind of effects. Very insecure indeed. Can anyone explain why in the whole world something like this could ever happen, or is in fact an exploit/virus/worm?

Re:How come an app can do that?

[siride]

With Gentoo, packages cannot modify anything in the outside system. I don't know what precautions the .deb package system has, but based on what I see with RPM, I'm guessing not much.

Re:How come an app can do that?

[Xiph]

It's a driver installation, so the ordinary user doesn't/can't do it.

However, it's a proprietary driver, that you need to install to use the printer, so if that's the printer you have people install it, expecting it not to create security holes.
This might have been discovered earlier, if it weren't for the closedness of the source.

My guess is that it happened due to a coder writing the driver so, it requires root to use it.
Then trying to guess which programs requires the driver, then setting those to run as root. Silly, but easy to do.

Sounds like it was done without peer review, so i guess they only have one guy writing their linux drivers..
So why is it proprietary? well some places printers are encouraged(required) by law (enforcement) to leave secret and invisible watermarks.
If it isn't done in the printer, it's done in the driver, if it's open, it'll be removed.

Re:How come an app can do that?

[Anonymous Coward]

It seems extremely dangerous that a user can install something like that, with that kind of effects.

You have to be root.

You dumbass.

Re:How come an app can do that?

[krischik]

I expect that you install the drivers as root. The installation routine then sets suid to all applications which use a scanner.

And somehow I understand it - quite often I had to start xsane as root because the current user just was not able to access the scanner device - and I wanted that bloody scan now and not in half an hour problem searching session.

Martin

Re:How come an app can do that?

[PetriBORG]

It seems extremely dangerous that a user can install something like that, with that kind of effects. Very insecure indeed. Can anyone explain why in the whole world something like this could ever happen, or is in fact an exploit/virus/worm? It will require root privs to set up in the first place. It comes from the old UNIX method that "if you are privileged enough to have root, you should damn well know what you're doing." mindset. The problem is that apt-get, etc almost all require "root" or wheel access anyway to run. That means you're running a lot of program installers as root that probably you don't really trust enough to install in all parts of the system (see this as an example).

Re:How come an app can do that?

[Chrisq]

This seems like a good argument for user space drivers. That way only the device driver for the peripheral connection needs to be installed by root, and the printer-specific stuff can be safely installed by users.

Re:How come an app can do that?

[Anonymous Coward]

An app running as root can do anything it wants - and installers normally do run as root. The same problem exists on every OS: the administrator and the programs he runs can do retarded things.

The question I want to ask is why there is a driver developer working for Samsung who is able to understand the function of the setuid bit but not the security implications of using it. It seems that there is a very special type of stupidity involved here, along with some extremely thoughtless design. Samsung is taking a big risk employing morons like that.

If the guy can't understand the security implications of the setuid bit, which are well documented and not that complex, he should not be writing software.

Re:How come an app can do that?

[plague3106]

This might have been discovered earlier, if it weren't for the closedness of the source.

Really? It could not have been detected by noticing that OpenOffice is not SetUID? I believe there is even a package for linux that monitors binaries in /bin, /usr, etc. and notifies you immediately if permissions have changed for anything. I know such a package was available for RedHat when I was using that. That could not have detected this sooner?

Stop with your lame "thousand eyes" theory. Apparently those thousand eyes couldn't see a permissions change on their own systems.

Re:How come an app can do that?

[Anonymous Coward]

Stop with your lame "thousand eyes" theory. Apparently those thousand eyes couldn't see a permissions change on their own systems.

But it's been seen. Is that then proof of the thousand eyes theory?

(you fucking idiot)

Re:How come an app can do that?

[Dr. Manhattan]

Stop with your lame "thousand eyes" theory. Apparently those thousand eyes couldn't see a permissions change on their own systems.

Apparently someone did... else we would not be reading this story.

Re:How come an app can do that?

[Anonymous Coward]

(you fucking idiot)

Great parenthetic slapdown -- bravo!

Re:How come an app can do that?

[siride]

You do realize that userspace drivers and permissions are orthogonal concepts? Userspace drivers still would probably need to run as root to be able to properly access system resources.

Re:How come an app can do that?

[plague3106]

Yes, eventually, but not as the OP claimed with This might have been discovered earlier.

Re:How come an app can do that?

[TheCRAIGGERS]

I'd say there's a big difference between somebody doing this knowingly, and a script that runs during an install that does it behind our backs.

Re:How come an app can do that?

[rbanffy]

These are no packages. It's an installation program you run as root.

Really Windows-style.

Re:How come an app can do that?

[rbanffy]

I would like to add that, had the driver writer done his/her job and made it to work the proper way (SANE for the scanner, CUPS/GhostScript for the printer) and maybe something more specific for the fax part, he would never, ever, face any problem.

It's lame and inexcusable.

Re:How come an app can do that?

[imroy]

The question I want to ask is why there is a driver developer working for Samsung who is able to understand the function of the setuid bit but not the security implications of using it. It seems that there is a very special type of stupidity involved here, along with some extremely thoughtless design. Samsung is taking a big risk employing morons like that.

My guess: the programmer or programmers is/are more experienced with the Windows environment, where this sort of tom-foolery with permissions and privileges is standard practice and often necessary. So they know that to get around some problem, certain programs have to run as root/administrator. But they are unaware (or minimally aware) of the decades of security vulnerabilities and their solutions that are a part of the UNIX world. It may sound like the standard Slashdot cop-out, but once again we can likely blame Microsoft for another security vulnerability, even though it does not involve their software at all!

Re:How come an app can do that?

[Dr. Manhattan]

Yes, eventually, but not as the OP claimed with This might have been discovered earlier.

Actually, 'chmod' calls do tend to stand out. Anyone doing a security review of source code (and drivers do get that kind of attention) would note them.

I think one of the reasons this took a while to find is that it's so monumentally moronic no one would have believed anyone would actually try that. I'm still a bit dumbfounded, myself.

Re:How come an app can do that?

[cortana]

Only if you blindly add unaudited and untrusted third party repositories to apt's sources.list.

This would never happen if the driver was installed from the Debian package repository, because the Debian packaging policy does not allow packages to mess with each others files in this way. :)

Re:How come an app can do that?

[Chrisq]

They are not directly related but can work together. for example a USB driver would need to be a superuser driver to access the hardware, but a printer driver could run in user space and use normal security access rights to determine if it could access the USB device.

Re:How come an app can do that?

[und0]

I don't know what precautions the .deb package system has, but based on what I see with RPM, I'm guessing not much. None. I mean, every unofficial deb package out there on the interweb potentially could be a trojan. There was a precedent some months ago when, IIRC, a Debian developer modified a package on his personal repository that changed the user desktop background to ring a bell on the clueless people with scarily crowded apt "sources.list".

I suppose the same could be done with Gentoo, modifying an emerge script, but never used a Gentoo distribution...


P.S. for the record, i know that the packages are PGP signed and i trust my Debian Sid ^_^

Re:How come an app can do that?

[a.d.trick]

Sounds like it was done without peer review

You know, if they found one developer that stupid, they can probably manage to find another one two.

well some places printers are encouraged(required) by law (enforcement) to leave secret and invisible watermarks.

Required! Don't we have laws against that? Anyhow, that kind of stuff would be implemented at the firmware level or lower. It's not a viable excuse.

Re:How come an app can do that?

[Xiph]

Ok, i guess i have to reply by now.
I wrote "This might have been discovered earlier".
I did not write "This would have been discovered earlier".

I deliberately chose the first of those two sentences!
Because I'm not that horribly stupid to believe that it's infallible, just that it has one more(imo decent) station it can be caught at.

I considered the first post like this to be flamebait, i marginally consider your post flamebait, but here I am biting.
Next time, you read something, remember to read all the words, most of them mean something.

Re:How come an app can do that?

[baadger]

Thats not really true, Gentoo ebuilds are scripts which run at root to install the software via various arbitrary methods (everything from your standard configure, make, make install to nvidia's proprietary driver installer) into a "work" directory. It does have provisions for establishing a 'sandbox' but I believe it's done via library trickery (wrapping file system calls by messing with the LD PATH maybe?) rather than something like a chroot operation. I would argue that deb's and rpm's are inherently more secure because you can list the files within them *before* running the install process to see what is going to be installed and where (Of course this is just the nature of a source based distribution, not a flaw)

That said this discussion is irrelevant anyway because the whole point of community package repositories and package managers is to vet software for quality and to make sure packages installed and uninstalled correctly. Gentoo's portage, for example, automatically fixes up permissions on things going into /bin, /lib, /usr/bin, /usr/share when copying the "work" compilation into the active filesystem.

What this Samsung news proves is that the *nix way of using package repositories and managers and doing things through a common (un)install process catches outrages like this, whereas with Window's you're essentially at the mercy of some sloppy installer developer somewhere, i.e. one small group of people. Good stuff. On the other hand it also demonstrates how the rise in popularity of open source platforms is going to put increased pressure on open source communities to catch things like this and it will be hard for many developers to not give in to the Window's ways of doing things.

Re:How come an app can do that?

[DrSkwid]

I don't remember the Caxton having a marking system that tracked it back to each press.

Re:How come an app can do that?

[DrSkwid]

> The same problem exists on every OS: the administrator and the programs he runs can do retarded things.

There's your problem then : root is a design fault

Re:How come an app can do that?

[fritsd]

The package you describe is called "checksecurity" although it doesn't notify you immediately, I think it runs a nightly cron job.

apt-get install checksecurity

Of course its effectiveness depends on the system admin actually reading its report :-)

Re:How come an app can do that?

[plague3106]

I guess you miss my point; you don't need open source to see the side effects of the driver installation. This could have been discovered just as easily by someone running Tripwire after each install, whether the source was opened or closed has no bearing on how quickly this COULD have been discovered. There may be other cases that would back up your theory, but this is certainly not one of them.

I'd argue that open source isn't offering another station; because the source is open, a particular package may be implicitly trusted by the installer. As I pointed out with a comment on GCC, just because you have the source does not mean you are safe or can even be sure of what the compiled binary will do.

Re:How come an app can do that?

[Tanuki64]

As I pointed out with a comment on GCC, just because you have the source does not mean you are safe or can even be sure of what the compiled binary will do. Correct, but the probability is higher that problems are seen and fixed earlier. Personally I never read the code of a open source package I am going to install. This would be impossible. But I read the code of several packages to learn how it worked, to learn how to use it when the docs where bad not unavailable or to jump start my own open source project. So even though I don't actively search for security risks, I might have found some by pure chance. I think this is the more likely scenario of the 1000 eyes principle of open source. Not perfect, not as good as some open source evangelists claim it is, but by far better as anything a closed source program can offer.

Re:How come an app can do that?

[HiThere]

It's not clear to me that it's improper to give the blame to "the Window's ways of doing things.". Good arguments have been made that attribute the cause to that, and no significant responses have countered them.

Re:How come an app can do that?

[Sancho]

I've read a few stories about this issue, though I've not read how it was initially discovered.

You're right that someone might feel that FOSS is more secure, and thus be less likely to vet it themselves. If everyone does this, this means that the 'thousand eyes' theory is flawed. However, it seems likely that this flaw was discovered when someone took a closer look at their /bin, either because an update caused printing to fail, or because their daily scripts noticed the changes. Either way, with a closed source binary, this is basically the first opportunity you have to notice the strange behavior. No one is going to install the software and then check their system for weird behavior. At best, they might use tripwire, which would alert them quickly to the changes. Manual inspection of changes made to the system after software is installed simply doesn't happen unless you're suspicious in the first place. Hell, FOSS could make changes to the system that you didn't expect.

If the code was open, however, at least the possibility would exist. All of the checks you and I mentioned above would still be true--tripwire would fire if FOSS made these modifications. The SUID checking scripts would note the new files. An update to Open Office would still cause printing to break. In addition, though, people could read through the source. It's one more way that people might notice that something's up. Because of the additional methods of detection, it might have been discovered sooner. Maybe it wouldn't have--we'll never know. But that chance exists, and I think that's all that the poster you've been replying to was saying.

Re:How come an app can do that?

[SanityInAnarchy]

Sadly, this kind of stupidity is too common, even in open source.

For example: Far, far too many web apps, particularly stuff written in PHP, even good stuff written in PHP (like Drupal), tell you to "chmod 777" on some directory if you get any kind of security issues, without breathing a word about what that actually does.

Windows coders

[erroneus]

If I'm not mistaken, this is how Windows got as bad as it is.

This particular incident cannot be protested enough. If this sort of thing becomes common, End-user Linux will become as corrupted as Windows.

Re:Windows coders

[suv4x4]

This particular incident cannot be protested enough. If this sort of thing becomes common, End-user Linux will become as corrupted as Windows.

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:Windows coders

[jkrise]

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.

Not sure why I'm feeding a troll, but he never mentioned about Linux being good for a few apps. Linux (or the Unix multi-user security system) is good enough for the entire web, provided people who write apps do so in a transparent way. Doing things in closed-source proprietary drivers and calling the operating system useless is a bit disingenious - but something an MS shill or Apple fanboy would do.

Re:Windows coders

[suv4x4]

Doing things in closed-source proprietary drivers and calling the operating system useless is a bit disingenious - but something an MS shill or Apple fanboy would do.

Maybe an MS shill or Apple fanboy or [insert tired cliche here] would call Linux useless. Good thing I didn't.

Would a Linux fanboy bend my words to fit his black-and-white world?

Re:Windows coders

[CaptnMArk]

No, the problem is people programming applications using the principle of least resistance.

Re:Windows coders

[erroneus]

No, that is not my point.

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:Windows coders

[Anonymous Coward]

Oh, bullcrap!

It was stupid when programmers did it under Windows and it is stupid when they do it now under Linux. It has nothing to do with popularity!

Re:Windows coders

[rbanffy]

No. It's still far more secure than Windows (or Macintosh, largely), since, in this case, you have to run a proprietary installer for a particular brand of printer/scanner I happen not to use (and that I won't recommend to anyone) and not use the mechanisms for software management built into any modern operating system (such as Red Hat, Debian or Gentoo).

Windows requires to run installers at elevated privilege levels to install things as trivial as a music players and, those, not rarely, intermingle themselves into the operating system in ways it makes impossible to get rid of them after you no longer need them.

Re:Windows coders

[drsmithy]

Windows requires to run installers at elevated privilege levels to install things as trivial as a music players and, those, not rarely, intermingle themselves into the operating system in ways it makes impossible to get rid of them after you no longer need them.

Windows, like Linux, "requires" nothing of the sort.

Re:Windows coders

[ajs318]

Much of the security of Linux comes from the Open Source nature of much of the software that makes it up.

We (that is, the ones who have used Linux since the days before it became all cuddly) use Linux because we want to keep full control of our systems -- and we know that i-tal software is the first of many steps towards that goal. But most people don't understand the implications of Closed vs. Open Source, and will choose -- because they don't know any better -- to pollute their system with a closed-source driver rather than forgo the use of a particular piece of hardware. There are only two ways out of that: you could outlaw the whole deplorable practice of keeping Source Code secret from users; or you could educate every single person in the whole world about the basic principles of computer security, and prevent the ones who can't or won't take responsibility for themselves from ever touching a computer.

Which one do you think is going to be easier?

Re:Windows coders

[suv4x4]

It was stupid when programmers did it under Windows and it is stupid when they do it now under Linux. It has nothing to do with popularity!

The stupid population flocks to popular things. I mean, look at Slashdot before it was popular, and see the all the garbage it has now.

Re:Windows coders

[Omnifarious]

If those driver's were Open Source, this would've been fixed by now and the Samsung programmer's would've been taught a small lesson in how to program properly. As it is, they're probably sitting there saying to themselves "Why does anybody care? It works, doesn't it? We did just fine and all these idiots are just nitpickers, why don't THEY write the stupid driver!"

The problem with Windows is the development model, not the number of people writing code for it.

Re:Windows coders

[LordEd]

Doing things in closed-source proprietary drivers and calling the operating system useless is a bit disingenious - but something an MS shill or Apple fanboy would do.

Its only fair. Anytime any 3rd party application on Windows causes a problem, it must be the operating system's fault for allowing the user to do it. It looks like Linux allowed a user to do something you didn't expect.

Re:Windows coders

[erroneus]

You can also outlaw drugs, cigarettes and alcohol. I'm not quite convinced that getting rid of proprietary solutions is the most likely-to-succeed solution. People want what they want and will often accept it in whatever form it takes regardless of the long-term or global effects/consequences. This is both the symptom and the problem I suppose.

But let's take, for example, the problem of proprietary video drivers. Why won't they release the code when it's the hardware that they are selling? The problem is "secrets" and presumably dirty little secrets. They want to call them trade secrets and licensing issues. They "own the code" and can, in theory, do whatever they want with it. But here's the reason I believe they want to keep the code secret:

Performance on "cheaper" hardware is actually being held back depending on the model of the hardware the driver detects. Let's say the Radeon driver sees a Radeon x1000 where the driver will support everything from a Radeon 8000 to X1600. My suspicion is that even though the x1000 and the x1600 are capable of the same performance, they write the driver in such a way that x1000's performance is lower than the x1600 to encourage people to buy the higher-performing device. If these drivers were open-sourced, these performance inhibiting techniques could be exposed and people would be able to enhance the performance of their older hardware and not be inclined to upgrade.

Mind you, this is my opinion, or more correctly, my guess or my suspicion. I have no basis in fact for the scenario I describe above. But I believe we have seen these sorts of things in the past and we'll continue to see it in the future.

The proprietary driver model also enables a pre-planned obsolescence scheme. Consider the problem of wanting to sell more devices when the open source community keeps writing software that makes good use of really old hardware. So what doesn't work well for Windows XP, for example, would work quite nicely in Fedora 7 with a 2.6.x kernel. With open source drivers, people could extend the life of any given device. With closed source drivers, they can pick and choose which hardware to "fall out" of support even though it would be a perfectly easy thing to support. We have seen where with each new release of ATI's proprietary drivers, the range of supported devices keeps shifting to make obsolete some pretty decent hardware so that your choices are limited to not upgrading your kernel or distro, or upgrading your hardware which is sometimes not an option for some users of laptops and some machines that come with the video hardware embedded. The threat and power of a hardware manufacturer to force obsolescence onto a user's system is very good for the manufacturer and very bad for the end user... one might even consider it a form of consumer abuse.

Re:Windows coders

[suv4x4]

And now Microsoft are locking Windows down for that very reason, so that you need to sign ring-0 code (eliminated random garage Joe-s randomly writing kernel mode code).

Linux can't do that since everything is open. Bummer.

Re:Windows coders

[DrSkwid]

MSI's write to /Program Files/

Non-privileged users can't write to /Program Files/

Installers won't let you install programs in $HOME

ergo you HAVE to log in as root and run the installer

yet hardly any Linux programs need their files in specific places and are quite happy using $HOME
and if they are not you can always run them in a chroot.

Re:Windows coders

[sjames]

Using linux is not the issue. Installers doing increadibly stupid things as root is the problem. The security model in Linux (that is, Unix) is quite flexible, but only if it's used properly. Perhaps an analogy is in order (no cars, I promise!)

Consider the door to a house. The door is solid steel and is fitted with the world's strongest deadbolt. We'll assume the walls and windows are equally proof against break-in. None of that is at all useful if the homeowner allows a stupid contractor to tape the housekey to the outside of the door. Samsung is that stupid contractor in this case.

Re:Windows coders

[erroneus]

Signing drivers has been proven to be ineffective for several reasons:

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

Re:Windows coders

[weicco]

And that is why major Anti-Virus vendors are having troubles for example with Vista. I was writing NDIS intermediate filter drivers back in 2000-2001. Everything worked out fine when we followed MSDN and DDK documentation. Then we decided to test how our driver works when there's AV and FW drivers running in kernel at the same time with our stuff. Kab00m! Right after F-Secure was installed, all hell broke loose. It was Windows Reinstall Time. Luckily we kept plenty of Ghost backups which made the process faster. Same problems arose with some other softwares but surprisingly, the smaller the vendor, lesser problems arose...

And what was causing this? I still don't know for sure but we speculated that F-Secure bypassed kernel interfaces and hooked itself to some undocumented internal APIs or something. I really don't know why they did it, if they did, since everything that AV and/or FW driver ever needs is nicely documented in DDK. I also remember reading here from Slashdot that because of this kind of behaviour MS was forced to freeze some internal interfaces that was supposed be changed between patches or something.

So please, programmers, Read The Fine Documents :)

Re:Windows coders

[sqlrob]

Installers won't let you install programs in $HOME

That's a bug in the installer. I've written stuff under Windows that installs from Guest on up.

Re:Windows coders

[suv4x4]

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.

1. Prove it. What you're saying is absurd, if signatures where that easy to forge, the whole e-commerce industry would be falling apart (and not only).

2. That's the case with XP. Vista doesn't allow *at all* unsigned kernel drivers to be installed. The user has no choice but.. well, he has no choice. He won't install the driver.

Re:Windows coders

[Nexx]

How exactly are application limitations the fault of the OS?

My employer has a program here that only requires elevated priviledges for installing itself a service. Otherwise, it's quite happy running anywhere it damned well pleases, whether that's C:\Program Files\ or \\some_server\some_user\proggie. Since it's optional to run this product as a service, it doesn't require the use of elevated priviledges.

Re:Windows coders

[erroneus]

1. Prove it. What you're saying is absurd, if signatures where that easy to forge, the whole e-commerce industry would be falling apart (and not only).

Must I prove it? Well, okay. go here:

http://www.eweek.com/article2/0,1759,1995993,00.as p

Then, go on to read this:

http://www.symantec.com/avcenter/reference/Securit y_Implications_of_Windows_Vista.pdf

I'll admit that those above are related largely to Vista, but the concept of driver signing started in Win2000 and each release did manage to add more to the original notion.

And while it's true that locking out unsigned drivers entirely is a good deal, I think it will demonstrate more problem than benefit. The real problem will result from forged signatures and if you would like to assert that people out there would not be able to break the encryption involved in the process, please stand up and make yourself humiliated publicly. If it can be encrypted, it can be decrypted. If there is a key, it can be unlocked. These are not laws I just make up, these are laws of nature. These security mechanisms rely on secrecy and if you think it through to conclusion, no secret can withstand the determination of the crackers that exist today.

2. That's the case with XP. Vista doesn't allow *at all* unsigned kernel drivers to be installed. The user has no choice but.. well, he has no choice. He won't install the driver.

Uhm... people are actually *using* Vista? Okay, that's sarcasm mostly, but I think it's pretty clear that a strong and dominant portion of the population are resistant to Vista for the moment and will continue to be resistant, I predict, until no other options are available.

Re:Windows coders

[rbanffy]

OK. It only happens that most Windows programs come with installers that run under admin privileges and scatter files all around the hard disk (under Program Files, under "Program Files" even when running under localized versions of Windows that would like to call it by other name, under \windows, \windows\system and so on), that write settings in an obscure database that gets corrupted, fragmented and dirty from time to time and that have to be called again when you are uninstalling the program so they can undo the mess they created (or create an even bigger one).

I have written my share of Windows programs that do not require installation. It's just not the norm.

Re:Windows coders

[suv4x4]

Must I prove it? Well, okay. go here:


As I expected, you're full of it. None of this regards *signature forging*. It's about bypassing the signature *checking*, and Rutkowska never demoed her dangerous concept afterwards (vaporware?), citing it needs months of work before it's really undetectable (and they demanding someone pay her for months of work, no one did).


I'll admit that those above are related largely to Vista, but the concept of driver signing started in Win2000 and each release did manage to add more to the original notion.


Is it always very hard for you to admit truth?

Uhm... people are actually *using* Vista? Okay, that's sarcasm mostly, but I think it's pretty clear that a strong and dominant portion of the population are resistant to Vista for the moment and will continue to be resistant, I predict, until no other options are available.

Pathetic. No, you idiot*, I've not been talking about Vista, I've been talking about Windows 3.11 all this time!

* Not meant as insult, just observation.

Re:Windows coders

[KarmaMB84]

Blue Pill has absolutely nothing to do with code signature forgery. Code signatures are encryption based so forging one would require that you obtain the signatory's key.

Re:Windows coders

[erroneus]

The best sign of a bad argument is when someone resorts to insults. There's two criticisms of *me* rather than the argument in there. Get with the program, you're falling behind.

So, since you ignored (or acknowledged) that encryption and encryption based signing can be forged as a matter of mathematical principal, the fact that no presently living example of such doesn't diminish the possibility. (Further, and I really wish I could find it, there was a case back in Windows2000 when the keys to several publishers got out and were subsequently and quietly revoked by Microsoft during one of the service pack releases... it too was mentioned on slashdot, but I guess it's just too old for google to find easily.)

But the bottom line is that you touted driver signing as the means by which Microsoft has made up for their weaknesses and I think I have presented ample indication that it's fallible both by threat of forgery and by cracking or bypass. Cracks and bypasses are available on the pirate bay if you need an example of that.

But truly, back to the point. Windows suffered, suffers and will always suffer from the bad programming practices of DOS/Windows programmers so long as Microsoft maintains a level of backward compatibility that requires emulating bugs and undocumented features.

The case of the closed-source driver install misbehaving by changing permissions and generally abusing root access is not necessary and generally bad behavior that can and will lead to the mess that we call Microsoft Windows. By and large, Linux does not suffer from that problem. This could change -- the potential is real. This is the original point I was making. That without vigilant care in coding practices and persistent rejection of bad practices, these sorts of things will creep in and reduce the quality and effectiveness of the Linux environment at large. Calling attention to this as bad behavior and pointing out what this leads to is what I intended to illustrate.

But okay, we get it. You are a Windows defender. You probably make your living from Windows in some fashion and you may even be a coder yourself. But here's the problem with your style: you don't know or understand Linux. If you did you wouldn't have made the assertions you made previously (that linux doesn't have code signing). And the reality of most Linux users is that they likely know Windows at least as well as you do or better than the average user because, like it or not, Windows is here, it is now and it is the majority and we all have to deal with it in one form or another. We prefer Linux because, like OS/2 was, it's technically better in so many ways that doesn't involve marketing or popularity contests. It's also better because it's not quite so tainted with legacy or backwards compatibility baggage that encumbers Microsoft's code. (Did you read the comments that were extracted from the leaked Windows source code? I did... it painted a pretty interesting picture of things where maintaining backward compatibility with buggy and misbehaving applications were concerned.) And frankly, while bugs and problems pop up just about every day, Linux just isn't as polluted as Windows is. My message is that pollution of the Linux environment should be resisted and rejected at every turn.

Re:Windows coders

[suv4x4]

The best sign of a bad argument is when someone resorts to insults.

The best sign of a bad argument is flawed logic and poorly checked facts. It's not about presentation but substance, the thing you lack. I didn't even read what you wrote past that first sentence, first get right all things you got wrong so far. But I won't care again anyway.

Re:Windows coders

[erroneus]

Could there BE a more obvious self-declaration of who you are?

Re:Windows coders

[fatphil]

You're conflating running an an application, that which users would be expected to do, and installing an application, something which often requires administrator privileges.

Of course the OS is at fault if it lets applications escape the sandbox (memory management, file permissions, socket openning restrictions etc.) that they ought to be running in. Of course it's the OS's fault if it has nothing even approximating such a sandbox.

And of course it's the installer's fault if it demands administrator privileges and then abuses them.

These are two entirely different issues.

Re:Windows coders

[fatphil]

Amen!

One thing that really pissed me off about Linux Journal was how every alternate month there's be an article about running some wanky application as a kernel module "for speed" or "for efficiency". For bleedin' idiocy, mate.

Then again, I shamelessly veer towards a micro-kernel preference.

Personally, I think Linux dropped below the 'cobbled together shit written by bodgers for idiots' about 3-5 years ago. I still run it on 6 out of my 8 machines though, as I've found nothing better.

Re:Windows coders

[fatphil]

... dropped below the '... shit ...' *horizon* ...

suid is evil!

[PetriBORG]

Once more boys and girls, say it with me now, SUID IS EVIL! :-)
Nothing but the programs that absolutely have to should be run as root.

Is there an English (not some auto-translated forum) site covering this? I think its talking about this suid run printer driver?

Re:suid is evil!

[StripedCow]

And repeat after me: "proprietary" is even more evil than suid!

Re:suid is evil!

[nagora]

Once more boys and girls, say it with me now, SUID IS EVIL! :-)

SUID does not have to set id to root; my printing scripts are all setuid to "lp"; my mail servers are suid to "mail". This is a good thing.

TWW

Re:suid is evil!

[PetriBORG]

And repeat after me: "proprietary" is even more evil than suid! HEH! Yes I agree with you, I've running 100% linux for a long time now for that reason. With that said though, there are lots of complicated pieces of code that I and everyone else just "trust" to work. Part of that trust comes from it being OSS, but a larger part I'd hope comes from a history of good work on the source's part.

Re:suid is evil!

[PetriBORG]

SUID does not have to set id to root; my printing scripts are all setuid to "lp"; my mail servers are suid to "mail". This is a good thing.

Yeah, true enough, but in the context we're all talking about, we're talking about suid as root specifically. Since suid just runs as the owner of said executable and this executable is owned by root for no good reason, again we see the problem ey? I should have probably been more careful/specific though yes.

Re:suid is evil!

[Ash Vince]

"proprietary" is even more evil than suid!

No it isn't.

I write proprietary code for a living as do plenty of other people here I'm sure. Why should everybody have to release code as open source? Some of us would like to get paid for what we do without having to "add value" by offering support services as well.

In terms of Linux drivers there are several reasons why companies do not create or want open source drivers for their hardware. The most obvious one being that you are trying to keep exactly what the hardware does secret to make it harder for your competition to copy its functionality.

Personally I don't give a shit whether the drivers on my system are open or closed source, I just want them to work and closely match the functionality of the windows drivers.

I have no interest in looking through the code that makes up every driver on my Linux box any more than I would like to do a code audit on every version of Linux kernel before I compile it. Are you going to tell me that you have looked through the code for the various open source apps you use or do you take most of them on trust just like proprietary apps? Certainly for me this is far too much like what I do for a living to do it every night when I get home as well.

I would not want to use this particular driver as it is quite obviously a worthless piece of badly written junk but this does not mean that all proprietrary drivers need to be. Also note that this driver was revealed to be a piece of crap without needing access to the source code.

For a good example of a closed source driver check out the nvidia driver. It works and has never casued me any problems. I know it has had some security holes in it but so have plenty of open source drivers.

I do think that the open source usually produces better quality software if the project is well maintained, but not this model is not suitable for every piece of code produced.

Re:suid is evil!

[sholden]

So "suid root is evil" then, which is completely different than "suid is evil" - and not everyone can read minds across the interweb...

Re:suid is evil!

[ajs318]

I write proprietary code for a living as do plenty of other people here I'm sure. Why should everybody have to release code as open source? Some of us would like to get paid for what we do without having to "add value" by offering support services as well.

Some people would like to be paid for going to the toilet, but it ain't gonna happen.

At any rate, there's such a thing as software which you get in Source Code form, but have to pay for and aren't allowed to copy or distribute. There's no evidence that non-availability of Source Code prevents unauthorised distribution. There is evidence that non-availability of Source Code fucks people's computers up.

In terms of Linux drivers there are several reasons why companies do not create or want open source drivers for their hardware. The most obvious one being that you are trying to keep exactly what the hardware does secret to make it harder for your competition to copy its functionality.

You aren't allowed to keep exactly what the hardware does secret from its rightful owner. That's just Common Law Property Rights.

Personally I don't give a shit whether the drivers on my system are open or closed source, I just want them to work and closely match the functionality of the windows drivers.

And the best way to achieve that is by making the Source Code available, so that as many people as possible get the opportunity to inspect and improve the drivers. If the driver belongs in the kernel, so much the better. Linux kernel developers are by definition some of the world's best programmers.

I have no interest in looking through the code that makes up every driver on my Linux box any more than I would like to do a code audit on every version of Linux kernel before I compile it. Are you going to tell me that you have looked through the code for the various open source apps you use or do you take most of them on trust just like proprietary apps? Certainly for me this is far too much like what I do for a living to do it every night when I get home as well.

This is a variant on the Argument from Incredulity, aka Argument from Limited Imagination. As usually presented in places like Pharyngula it goes along the lines of "I can't believe ___ could have happened, so God must have done it." Here, we have "I can't believe anybody would read the Source Code so nobody does it". Same argument. Still a phallacy.

I would not want to use this particular driver as it is quite obviously a worthless piece of badly written junk but this does not mean that all proprietrary drivers need to be. Also note that this driver was revealed to be a piece of crap without needing access to the source code.

It was found to be a piece of crap by studying such parts of the Source Code as were available. Who knows what horrors would be revealed, had anyone dared look further?

For a good example of a closed source driver check out the nvidia driver. It works and has never casued me any problems. I know it has had some security holes in it but so have plenty of open source drivers.

Slave: My master is a good master! He is better than some masters, who make their slaves work in forty-five degree temperatures. At least my master lets me stop working for awhile when it gets to 40 degrees. And he feeds me every day. Even some free people don't get a meal every day.

You're deluding yourself if you think an Open Source driver would be worse.

I do think that the open source usually produces better quality software if the project is well maintained, but not this model is not suitable for every piece of code produced.

Have to disagree with you there. Keeping the Source Code hidden from end users (and -- probably more important -- developers; although

Re:suid is evil!

[Nikron]

Actually the nvidia drivers do not 'just work' for me (They cause my Xorg to freeze if I kill a compositing wm & etc). But ironcially, I agree. While in theory I'd like most of my stuff to open source, the odd driver and program can be closed. As long as they work properly, and aren't huge security hazards.

Re:suid is evil!

[Anonymous Coward]

Not like it's that hard to find all those SUID SGID proggies either:

find / -type f \( -perm -04000 -o -perm -02000 \) \-exec ls -lg {} \;

Re:suid is evil!

[DrSkwid]

> For a good example of a closed source driver check out the nvidia driver.

Remote root exploit - check
Can't port it to other systems such as OpenBSD, Plan 9 from Bell Labs - check

Yes, that's a faultless example, well done.

> but not this model is not suitable for every piece of code produced

Why you think it is not suitable for Kernel Level Drivers I have no idea. Binary blobs are retarded, just like you.

Re:suid is evil!

[Anonymous Coward]

Don't forget the other half of the chant!

SUID is EVIL! :-)

SUID password is SPACEMONKEYPOO! :-0

Now, everybody together!

Re:suid is evil!

[HiThere]

WOW!!
I can understand why some of those run suid....but why all those games?

Well, ok. when they run they run with the permission of whoever is running them. And then it's surprising just how many games are installed as root.root (rather than root.games)

I *presume* that, say, falconseye, which I installed from the repository, isn't doing anything reprehensible, but why does it need suid when, say, ace_canfield doesn't?

That's almost enough to cause me to brush up on my C.

Re:suid is evil!

[fatphil]

"""
Once more boys and girls, say it with me now, SUID IS EVIL! :-)
Nothing but the programs that absolutely have to should be run as root.
"""

If nothing but the programs that absolutely have to run as root, then SUID is _perfect_.

It's not the tool that's flawed, it's the uses of the tool.
SUID bits don't kill people, sloppy programmers who rely on SUID bits kill people.

Re:suid is evil!

[Ash Vince]

Some people would like to be paid for going to the toilet, but it ain't gonna happen. I already am paid for writing proprietary code. So are an awful lot of people. The fact is that we all live in a capitalist world. I have spent a great many years campaigning against this, but I need to eat so I need money. Until I can sit at home and write Open Source code all day and still have enough money to live I would like to do what I enjoy.

Do you have a job? If so what do you do?

You're deluding yourself if you think an Open Source driver would be worse. I don't. I said in my post that open source produces better code and better software. Did you actually read it?

It was found to be a piece of crap by studying such parts of the Source Code as were available. Was it? I would have thought it was noticed because suid has a text based config file or that fact that the 'ps aux' command shows you what each process is running as.

Slave: My master is a good master! ..... Well, he's not that bad actually (Yes, I do have a master). He is currently sitting in the other corner of my office while I post on slashdot. That fact is that anyone with a job has a master of a kind. And for most of us not having a job is not an option. So we are all slaves we just get treated better than they used to. We get to choose our masters nowadays but we still have to work for someone.

I could quit my job, but I would find it very difficult to get another without a reference for the years I have put in. (Explaining a huge gap on your CV is hard in an interview when you get older).

By the way, I loved the link you posted as I am a godless liberal too.

Re:suid is evil!

[Ash Vince]

Remote root exploit - check I did say I know it has had exploits, but so does plenty on open source software.

Can't port it to other systems such as OpenBSD, Plan 9 from Bell Labs - check Who cares? How many of these systems need fast 3D video? How many apps are there for Open BSD that would take advantage of accelerated OpenGL? If there was enough demand then Nvidia would release a version for the OS's you listed. There isn't enough demand to justify the work involved. If you disagree, then write it yourself and you then have the choice of how you release it. You never know, nvidia might even offer to buy it from you. :)

Why you think it is not suitable for Kernel Level Drivers I have no idea.

Learn to read fuckwitt. I said not every peice of software. I did not say it was not suitable to linux kernel drivers.

I think it is up to the people writing software how they release it, and under what licence. If I as a developer want to keep something closed source, is that not my right?

Re:suid is evil!

[bogado]

Who cares? How many of these systems need fast 3D video? How many apps are there for Open BSD that would take advantage of accelerated OpenGL? If there was enough demand then Nvidia would release a version for the OS's you listed. There isn't enough demand to justify the work involved. If you disagree, then write it yourself and you then have the choice of how you release it. You never know, nvidia might even offer to buy it from you. :) All of that could, and have been said about linux also. Fact is that an open source driver is easily adaptable to any thing you could put a card into it even if it is none of the above systems. With closed driver no one has the option of trying to adapt, you have to ask and wait for the single source of drivers to create what you need and then all the "the demand don't justify the work" talk gets into the play.

The same rationale works with closed standards, why do you think the wii has only support for flash 7? The same reason that you cannot fit you amiga with a nvdia super ultra 3d bling.

Thank you!

[mwvdlee]

A big "Thank You!" to Samsung for demonstrating that propriatory code is inherently less secure than open source, if only because you can (could) get away with insecure code.

Re:Thank you!

[suv4x4]

A big "Thank You!" to Samsung for demonstrating that propriatory code is inherently less secure than open source, if only because you can (could) get away with insecure code.

A big "Thank You!" to you for the most of the world hating Linux.

Re:Thank you!

[mwvdlee]

The you are the welcome.

Re:Thank you!

[phoenixwade]

A big "Thank You!" to you for the most of the world hating Linux. there are over 6 billion people in this world. "most" would have to be more than half.... So you are asserting that more than three billion people hate Linux? Thank you for pulling another stupid statistic out of your ass..... I'd think you've be hard pressed to prove that more than half of the world even knows what Linux is, much less "Hating" it....

Re:Thank you!

[plague3106]

Wow, nice spin. The code itself is secure I image. I didn't notice in the translation that the driver itself was vunerable to an attack, just that the installer changed file permissions it shouldn't have. So this has nothing to do or not whether the code itself is secure, it has to do with what the binary is doing.

I guess you've never heard of an old UNIX compiler that inserted malicious code into otherwise clean source code, have you? Open source doesn't stop that, does it?

Re:Thank you!

[mwvdlee]

I actually feel kinda proud that he blames me personally for making 3 billion people hate Linux... imagine what else I could do with such enormous powers of persuasion? :)

Either way; anybody who can love or hate an OS needs to see a psychiatrist, just like you should if you love or hate a screwdriver, a hammer or any other tool.

Re:Thank you!

[mwvdlee]

Yes, I know about that GCC hack (i'm assuming this is what you mean since you mention both UNIX and open source) and about the trouble they had getting it out. But they did get it out. So yes, even open source can contain bad code. We're all only human after all. But it does get a lot harder to keep such things hidden, and when found it's a lot easier to get rid of it.

By "insecure code", people usually don't just mean unintended problems like buffer overflows but also about intentional functionality that creates security risks.

Re:Thank you!

[Znork]

"just like you should if you love or hate a screwdriver, a hammer or any other tool."

Mmm, when your purchasing department gets a nice lunch in exchange for exclusively buying screwdrivers and you're forced to use the screwdrivers to hammer in nails all day long, I wouldnt be surprised if you develop some excessively strong emotions towards both screwdrivers and the manufacturer of said screwdrivers.

Wether it's entirely rational or constructive is perhaps questionable, but as far as mental health goes it sure beats beating in the heads of the purchasing department personell with a fine selection of hammers. Such affect displacement is a common coping strategy and often quite healthy when the appropriate targets for the affect are even less suitable for various reasons.

Re:Thank you!

[jZnat]

That was the UNIX version of cc I believe. GCC doesn't work that way; instead, it bootstraps itself using a simple C compiler written in assembler (or something like that). Basically, if you can trust the compiler that compiles the compiler, and you can trust the new compiler, you're good to go. I trust the FSF more than that asswipe from Bell Labs. ;)

Re:Thank you!

[freezin fat guy]

propriatory code is inherently less secure than open source, if only because you can (could) get away with insecure code

Perhaps that should be "...if only because you can (do) get away with insecure code"

While open source may not prevent someone from releasing poor code it does bring it to light in a more efficient manner. Naughty things go on behind closed doors. When there is no place to hide one tends to demonstrate a little more responsibility. So it is with code.

Re:Thank you!

[sconeu]

That "asswipe" is Ken Thomson, who (co-)invented Unix.

The compiler in question was the AT&T Unix cc.

See his ACM address Reflections on Trusting Trust.

Slipping

[Joebert]

Am I imagining things, or are systems that are supposed to be more secure than others getting caught with their pants down alot more lately ?

Maybe all the boasting has got people feeling too comfortable, letting their guard down.

Re:Slipping

[Slashcrap]

Am I imagining things, or are systems that are supposed to be more secure than others getting caught with their pants down alot more lately ?

I'm guessing that you have nothing of interest to add to this discussion, or any discussion about security and are simply looking for cheap karma or to start a hugely tedious argument that we've all read a thousand times before.

As an alternative why don't you fly over to the UK and suck my big hairy cock, and in return I will promise to mod up one of your posts the next time I get the opportunity. You achieve your objectives and it will be a lot less annoying for everyone else.

Re:Slipping

[Joebert]

Isn't it nice being able to say what you really mean, without fear of getting your head caved in ?

Back to work slave...

Re:Slipping

[Tanuki64]

Am I imagining things, or are systems that are supposed to be more secure than others getting caught with their pants down alot more lately ? You can't really say that. Unless you include in 'get caught with pants down' when I post my IP and my root password here and than complain that this stupid Linux is unable to protect me against the simplest break in attempts.

Idiots click all and execute everything they find, no OS can be secured against idiot admins (everybody in possession of a root password is an admin) and still be usable. However, this does not apply here. The problem was not a shady program from a shady source. It was the official driver for a certain piece of hardware. The only protection against this is not to buy anything, which cannot be run 100% on open source. Not always an option today.

Red Alert!

[suv4x4]

"Major Security Hole In Samsung Linux Drivers"

Something possibly bad about Linux! I don't have time to analyze what happened, so I'll just shoot some of my best knee-jerk responses:

1. Because they're not open source! You see how only binary stuff is bad in Linux!
2. Samsung did it to undermine Linux!
3. Good, it shows someone cares and possibly uses Samsung's Linux drivers!

All of the above proves conclusively how great Linux is.

Re:Red Alert!

[Joebert]

4. This is the type of thing that usually happens on Windows.

The above shows just how similar the two really are.

Re:Red Alert!

[Anonymous Coward]

Just because an answer is in the form of a knee-jerk response, doesn't mean its not factually true. I'd say that you got 2 out of 3 right.

Re:Red Alert!

[CopaceticOpus]

In all seriousness, I would like to know the business case for not open sourcing these drivers. It seems to me they have everything to gain and nothing to lose. I can't imagine there's any significant technological secrets contained in the drivers themselves. The value they are selling is in the physical printers, and the drivers are just there to make the printers useful.

Why not open the drivers to a free process that will almost certainly improve them, and at the same time improve the company's image in the Linux community?

Re:Red Alert!

[TheCRAIGGERS]

I'm guessing it has way more to do with managers not knowing what OSS is, rather than an actual decision made with full knowledge to keep it closed.

Re:Red Alert!

[rbanffy]

"4. This is the type of thing that usually happens on Windows. The above shows just how similar the two really are."

No. Not really.

I had those drivers in a laptop some time ago because a client was dumb enough to buy equipment that had no decent Linux support. The fact highlights how bad it is to use the Windows approach of having to run installers at elevated privileges. Here, the only installer I run at elevated privileges is APT and it is reputed as quite safe.

As for Windows, you have to run such installers at elevated privileges just about evey time you need to make a change in your environment.

I ran the mentioned program once in about 6 years of active Linux usage. A Windows user runs one of those programs every month or so, to install even the most trivial things like cute emoticons for hotmail that come, most of the time, with some form of malware inside.

This is the lame Windows method escaping into Linux. Should be dealt with harshly.

Re:Red Alert!

[Anonymous Coward]

What does any of that have to do with the price of bananas?

(In other words, what exactly does your comment add to the discussion?)

Re:Red Alert!

[init100]

Here, the only installer I run at elevated privileges is APT and it is reputed as quite safe.

Whether APT is safe or not is irrelevant, since it only does what it is told by the package being installed. A bad package would be able to make APT do bad things, safe or not safe.

The trust is rather in the repository and its maintainers. We trust them that they know what they are doing, so that their packages won't mess up our systems.

Re:Red Alert!

[rbanffy]

"Here, the only installer I run at elevated privileges is APT system (software management tools and the repositories) and it is reputed as quite safe."

OK. Fixed that.

What were they trying to do?

[Anonymous Coward]

What were they trying to do that made them think OpenOffice needs to be setuid:root?

Windows ME(tm)(r) Security(tm)(r)(c)(*) now available on Linux, brought to you by Samsung(tm)(r)

Piece of crap

[Anonymous Coward]

The reason is most likely that this piece of crap driver tries to do ioperm calls on the parport (for USB printers!) and needs root for that. There is a howto somewhere in the web how to NOP out this crap from the binary. And never use a vendor-installer of course ..

Re:Piece of crap

[vtcodger]

***There is a howto somewhere in the web how to NOP out this crap from the binary. And never use a vendor-installer of course ..***

In the case of Samsung color laser printers, you have to use the vendor -installer because if it runs, it sets up a /etc/linuxprint.cfg that is needed by the Samsung filter ppmtosplc. AFAICS, the format of linuxprint.cfg isn't documented. (either).

OTOH, at least with the CLP-300 you can use foo2splc instead of the Samsung drivers. And I believe that some of the other models work with splix.

Re:Piece of crap

[Anonymous Coward]

I believe the author of Splix is already working on adding SPLC support, so that will do away with the need for either foo2splc and these Samsung drivers, and leave Splix covering the majority of Samsung printers.

Of course I really want to know why the author of the foo2* drivers doesn't just write them as normal CUPS Raster or Ghostscript IJS drivers in the first place, which would negate the need for it to be added to Splix in the first place, but I digress.

Install applications as root

[Simon (S2)]

I find it very disappointing anyway that anything you install on ubuntu is installed as root (at least that is the default way of doing it). Wouldn't it be übercool to be able to install applications as the local user, and drivers maybe as the "driver" user? I still think The Zero Install system is a nice and secure way to install software, and maybe one day we can extend this to install drivers as well, so that root access will almost never be required (a bit like Plan 9, or what SE Linux is trying to do).

Re:Install applications as root

[vadim_t]

Wouldn't change much really.

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:Install applications as root

[Depili]

Installing software as non-root is certainly possible, the distrowide package manager just can't do it without write access to the package database and software directories (having them world-writable would just be bad), but with little tweaking of dpkg or compiling the software yourself non-root users can install and run everything that doesn't require root access.

Re:Install applications as root

[MrNemesis]

If you allow the local user to install programs, then the local user is either;
a) going to need write access to all the usual locations (either /usr/bin and /usr/lib, or /opt) which wouldn't solve the problem TFA is on about
b) going to need to use some middleware that *does* have rwx access to /usr and a fine grained ACL system dictacting which users have access to what

"Driver" installs just need access to /lib.

Fact of the matter is that whatever user/process has the rights to install apps has the rights to fuck them up as well. Much like how windows can't help it if the user runs trojan_setup.exe.

As ther other poster noticed, things like SELinux offer incredibly fine grained access over what various users can and can't do, and if you go through the (fairly considerable) pain of setting it up it can give you an amazingly secure setup, but there's no way in hell it'd fly with everyday users or even most sysadmins. This is why Linux distros take such care with package management and like to retain control over their repositories - because they can't risk a third party, closed source package coming in and accidentally running a chmod -R 777 / on install. When you're dealing with companies that seemingly have little knowledge of Linux development and security models, this is a very real threat.

Re:Install applications as root

[nrgy]

I don't mean to disagree but everything of importance? All the apps I use are NOT located inside home and you can blame this on the companies that makes some of these but most do not like being outside /usr/local/*, if they do then I have to start messing with env variables which defeats the "It just works" linux has started to achieve. I wish all applications like gimp, xchat, etc installed into home instead of /usr/whatever.

I'm sure someone will chime in as to why its better or cooler to install in /usr/whatever but as a desktop os I kinda like how Apple does things when it comes to install locations. It would be nice to know $HOME/Applications stores all my installed software, one central location for all my applications instead of /opt/*, /usr/local, /usr/local/share, /usr/local/games etc. Like I said someone will probably tell me why I'm wrong for wanting this but for the average joe like myself it doesn't make sense.

Re:Install applications as root

[vadim_t]

Everything of importance == DATA.

You know, things like text documents, browser bookmarks, saved games, source code not committed to a source control system, applications settings, passwords (in files used by password managers), music, video, homework...

My $HOME is somewhere about 50GB in size. Important things are backed up of course, but I can't back up 50GB every day.

Now application binaries on a single user system are unimportant. So long you can keep your data, a full reinstall of system components could be done very quickly, unless you're running something like gentoo. Just backup your list of packages, batch install all of that, and if you kept your $HOME you can be back running in an hour or two.

Re:Install applications as root

[rbanffy]

Synaptic (and APT) are system-wide software-management tools and thus require root privileges. OTOH, it would be cool to be able to allow any user to install a program for himself and still keep it under package management.

Re:Install applications as root

[giorgiofr]

Average Joes like yourself typically launch programs via their graphical menu, so why would they even care where a program is installed? It might not make sense (actually it does, but that's a rant for another day) but why do you care?

Re:Install applications as root

[nrgy]

As I stated I care because it would be on central location for all my installed applications. Granted some Windows applications don't default install to this location but the average user knows most are installed in "Program files". I just tend to think it would be easier to have them installed in a $HOME/Applications directory. Also sometimes applications don't use config files stored in $HOME, sometimes even if they do you can customize the application even more by messing with files in the install directory, that process involves sudo root etc which is an extra step that could be delt with easier if they were in $HOME to begin with. Sure I understand my request isn't a huge one and yes I do get by with the current state of things, that however isn't to say that I still don't wish for a more central location preferably located in $HOME to begin with.

Re:Install applications as root

[ajs318]

You can: you just need a hacked version of apt which uses a separate database somewhere where you can write. You can then have your own $HOME/bin, $HOME/lib32 and $HOME/lib64 directories.

Better long-term would be for people to stop using compilers for user-space applications and write everything in interpreted languages (à la OLPC). This won't help with drivers, of course.

Re:Install applications as root

[Anonymous Coward]

There is supposed to be a pattern to the location of installs. Unfortunately it seems lately a lot of distros don't follow it. /usr is supposed to be for system components, and /opt is supposed to do what /Applications does in Mac OSX.

Re:Install applications as root

[FireFury03]

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 here you have discovered the fundamental problem. SELinux is appropriate for the job _because_ it allows very fine grained control over permissions. And very fine grained == very complicated - I don't believe you can have one without the other. This is probably why, despite it's flaws, standard unix permissions still persist to this day - they are really simple and so they are easy to use for most tasks.

Re:Install applications as root

[giorgiofr]

But such system wouldn't work well in a multiuser environment. Anyway, if you care about having this setup, you CAN have it - just recompile your apps with prefix=~/ and you'll be all set AFAIK.

Re:Install applications as root

[nrgy]

Im sorry but I wasn't talking about a multiuser environment, I was talking about a single user home environment. Also if you know where I can get the source code for software I pay for and not the open source stuff that is part of my distro I would sure like to know :D

Re:Install applications as root

[init100]

I wish all applications like gimp, xchat, etc installed into home instead of /usr/whatever.

May I ask what the benefits of such a system would be? If all applications went into your home directory, no other user on the system would be able to use them. Home is fine to install the oddball application that only you use, but any application that can be expected to be used by more than one user should be installed in a central location, available for all users.

as a desktop os I kinda like how Apple does things when it comes to install locations.

Do they install applications into your home directory? I cannot believe that they would be that monumentally stupid.

Like I said someone will probably tell me why I'm wrong for wanting this but for the average joe like myself it doesn't make sense.

Do you install all your Windows applications to your desktop, or to the system-wide "Program Files" directory?

Re:Install applications as root

[argent]

If you allow the local user to install programs, then the local user is either;
a) going to need write access to all the usual locations (either /usr/bin and /usr/lib, or /opt) which wouldn't solve the problem TFA is on about
b) going to need to use some middleware that *does* have rwx access to /usr and a fine grained ACL system dictacting which users have access to what

c) Going to have to install the software to some place like ~/bin and ~/lib, as you're supposed to do in a multi-user system if you're not the system administrator, and as people always used to do back when all this stuff was designed.

Re:Install applications as root

[giorgiofr]

Heh, good point. Bug your vendor until your software is customized to suit your needs? Maybe they'll listen!

Re:Install applications as root

[MrNemesis]

Yeah, I forgot about installing stuff in ~/, cheers for reminding me...!

Still through, for something like printer drivers (which you'll presumably want to be installed system-wide), installing to home isn't a very good solution IMHO.

Re:Install applications as root

[nrgy]

And what is wrong with not having other users be able to run an application? As I stated this is for a single user environment, that being so I never said you wouldnt have an option to install into a path such as the current system path if you were in a multiuser environment. Desktop on windows is the same as Desktop on linux, $HOME is not the desktop last I checked, yes Desktop is located in the home directory same as windows is in Documents and settings which is what $HOME is on linux. I don't see why or how moving USER installed applications into a Applications folder inside $HOME would be that big a deal. What is wrong with suggesting a root folder inside $HOME be a location where user applications are installed? It would be nice if say ubuntus synaptic could be launched as non-root and in doing so would install applications into $HOME or maybe another directory specified. I think some are missing the point of what I mean by USER applications, I'm talking about downlaoding firefox, picasa, my work apps, etc and running them in synaptic as non-root that installs them in $HOME/Applications. I'm sorry that you find browsing the confusing tree that /usr has become as not a problem, me on the other hand I get annoyed with it, not to mention their are so many similar tree structures that it gets confusing just where shit has gone. /usr/local/share, /usr/share, /usr/share/icons/, /usr/local/icons I'm sorry but $HOME/Applications/Icons would be nicer for my apps that I want to install just for my user.

Re:Install applications as root

[Electrum]

Better long-term would be for people to stop using compilers for user-space applications and write everything in interpreted languages (à la OLPC).

How do you install new libraries / modules / packages for these interpreted languages?

Re:Install applications as root

[argent]

Still through, for something like printer drivers (which you'll presumably want to be installed system-wide), installing to home isn't a very good solution IMHO.

Why not? Printer "drivers" are application configuration files and user level filters. There's no kernel involvement. If you installed OpenOffice in ~, why not install the drivers there?

In addition, there's no reason *anything* in the printer toolchain should need to be setuid root.

And there's no reason any installer should be changing anything anywhere but in its own files, let alone changing the permissions on applications.

Re:Install applications as root

[tal197]

What is needed is something like SELinux, which makes it impossible for applications to do things they shouldn't be doing.

For something like SELinux to be useful you need to be able to write a secure policy. If your installation system's installation model is "When a package is installed, it can write files to /usr/bin, /usr/lib and /etc" then writing a secure policy is basically impossible.

This is where something like Zero Install comes in. If you have a model* where installation is "safe" (Zero Install theoretically allows malicious users to install malicious packages system-wide, safely) then you only have to worry about writing policies for running things, which should be a lot simpler. e.g. the SELinux policy might say that the driver can read from the printer queue directory and write to the printer device.

Yes, "model". There may be implementation bugs too, but at least they can be fixed easily as they're found, assuming the underlying model is right.

Re:Install applications as root

[ajs318]

Mainly, as modules written in the same interpreted language. There'll be occasions when you will hit the limits and so have to compile stuff (or install a pre-compiled binary, but that's a nasty habit that we really ought to get people out of; disk space, processor time and internet bandwidth are all cheap enough today. Gentoo proved that compiling from source needn't require more than one command, and I'll be very surprised if there isn't a neat GUI front end for Portage these days) but hopefully this will be a rare enough occurrence for people to think before they perform such an upgrade. Later distributions most probably will incorporate all the binary modules that were available at the time of the freeze, so it might simply be a case of doing "upgrade all to latest" to get something you need.

Re:Install applications as root

[fatphil]

"""
If you allow the local user to install programs, then the local user is either;
a) going to need write access to all the usual locations (either /usr/bin and /usr/lib, or /opt) which wouldn't solve the problem TFA is on about
"""

Nonsense, he's never going to *need* access to /usr/bin or /usr/lib. If he's in a sufficiently privileged *group*, then he can install it in /usr/local/*. If he's not, he's going to install it in ~.

People who aren't in a sufficiently privileged group, and at that for a reason, certainly should *not* be allowed to install drivers.

Re:Install applications as root

[init100]

As I stated this is for a single user environment

I went back and read the post again. Where did you state that? You sounded like you wanted all applications to be installed in your home directory, multi-user system or not. And that is just plain dumb.

I don't see why or how moving USER installed applications into a Applications folder inside $HOME would be that big a deal.

It isn't. There is nothing wrong with installing one or a few applications into your home directory. I do it myself with e.g. Google Earth and a 32-bit version of Firefox.

It would be nice if say ubuntus synaptic could be launched as non-root and in doing so would install applications into $HOME or maybe another directory specified. I think some are missing the point of what I mean by USER applications, I'm talking about downlaoding firefox, picasa, my work apps, etc and running them in synaptic as non-root that installs them in $HOME/Applications.

Well, I see what you mean, and it could be a somewhat good idea. Still, most distributions are intended for multiple users, in which having each user install his applications into his home directory would be a waste of space. By the way, I'd also guess that many packages are more or less hardcoded to go into a particular spot, both in the package specification and in the binaries themselves. Many applications use hardcoded paths to find their required shared libraries. This wouldn't work in your scheme without altering the packages.

I'm sorry that you find browsing the confusing tree that /usr has become as not a problem, me on the other hand I get annoyed with it, not to mention their are so many similar tree structures that it gets confusing just where shit has gone. /usr/local/share, /usr/share, /usr/share/icons/, /usr/local/icons

You as a user of a package management system should never have to browse the system folders, and thus should never have to be confused by them. I can't see why you do it if you find it so confusing. What's next, requesting /home to be changed into "Documents and Settings" and adding drive letters, just so that the Windows user won't be confused? ;)

Let me be the first to say...

[RAMMS EIN]

quoi le baise? (senseless translation of 'wtf')

Does anyone have _any_ idea why they did this?

Fortunately, I don't use the drivers supplied by Samsung for my printer. They are crap. The foomatic one works just fine, though.

Re:Let me be the first to say...

[TheRaven64]

I am just guessing, but I would imagine that the drivers are in the form of a shared library that talks directly to the printer device. In order to talk to the printer device, the process to have permission to write to /dev/whatever, and the easiest way of doing this is to run as root. A more UNIX-y approach would be for the driver to be a filter that read something like PostScript from stdin and wrote printer commands to stdout. This could be run as a completely unprivileged user, with the printer daemon piping printer output through it. There are two reasons I can think of for not using this approach:

• It's a quick-and-dirty port of a Windows driver, which is not designed for this kind of interaction.
• The driver needs bi-directional communication with the printer (quite possible if the printer is really dumb and has all of the controller logic in software).

I don't know how something like CUPS handles the bi-directional issue. It would be nice if a printer driver filter could assume that file descriptor 3 was for reading from the printer, and that it should assume it was printing to a file (or via another filter) if this descriptor was not open at launch time, but I don't know if this is implemented.

to be fair

[SolusSD]

no user is going to be able to install such a dangerous "driver" without root access in the first place-- anyone can build a program, intentionally or accidently, that comprimises a system when ran/installed as root.

Re:to be fair

[Anonymous Coward]

no user is going to be able to install such a dangerous "driver" without root access in the first place-- anyone can build a program, intentionally or accidently, that comprimises a system when ran/installed as root

Yes, but when you install a driver, you normally assume that it's not going to make your system insecure. Why should it? Only a very badly designed driver would deliberately break your system security.

Sometimes drivers do accidentally introduce security problems. The Nvidia drivers for X have done this in the past, for example. In those cases, it's not bad design, it's an oversight of some sort, like a buffer overflow.

But this is not an oversight. A deliberate design decision has been made to break the Linux security model. A very special type of stupidity is involved: one that includes an understanding of the effects of the setuid bit, but excludes an understanding of the security implications.

Samsung should investigate this fully - who knows what other retarded decisions have been made by these guys?

Re:to be fair

[Shotgun]

A very special type of stupidity is involved: one that includes an understanding of the effects of the setuid bit, but excludes an understanding of the security implications.

Working in corporate America, this particular type of stupidity is all to common. The level of this stupidity is what I use to separate 'coders' from 'programmers'.
The programmer will recognize and heed the system implications of the choices she makes.
The coder just knows has to toggle levers and push buttons. He has an objective, and is oblivious to anything that isn't on a straight-line path to that point.

Ubuntu Forums Link

[cuby]

One buddy posted on Ubuntu forums:

http://ubuntuforums.org/showthread.php?t=500702

tickle my soul!

[Anonymous Coward]

linux has failed yet again. the genie is out of the bottle.

It come out...

[dmayle]

For those who can't read French, the Ubuntu forum is just a posting of a link to another forum where it was noticed. The posting, along with the interesting source can be found at http://linuxfr.org/forums/15/22562.html The interesting parts are:

wrap_setuid_third_party_application xsane
wrap_setuid_third_party_application xscanimage

wrap_setuid_ooo_application soffice
wrap_setuid_ooo_application swriter
wrap_setuid_ooo_application simpress
wrap_setuid_ooo_application scalc

The script copies the affected application's executable to one with a .bin extension, and replaces it with an suid wrapper script. This is undoable, but god, what a mess!

Okay, I couldn't overcome the lameness filter, go to the source to see for yourselves...

Re:It come out...

[squiggleslash]

Are they really setting a script setuid? Because that doesn't normally work.

Re:It come out...

[Obsid]

It's not actually a script but a binary executable. Still it's not meant to be anything else than a wrapper ...

Bad...

[Jaaay]

but this was the first time I heard of Samsung having native Linux drivers so as long as they stop screwing up peoples systems they might get some good publicity out of this ironically though I'm not sure if they deserve it.

Linux security

[krischik]

Year that's the theory - in praxis I quite often have to start xsane as root because - for whatever reason - the scanner device security is set to:

brw-rw---- root disk

Unix security is just not up to today's desktop hardware with scanners, usb stick and whatever else. The inflexible root-centred security system is no good for hot-plugin.

I like this little trivia: http://en.wikipedia.org/wiki/Unix#1970s - Multics - multi-user-os - unics - uni-user-os. And it is still that way - root is the only true user the rest are just cripple.

Martin

Re:Linux security

[siride]

That's quite the misinterpretation of the name Unix. It really was just a joke: "Unix is one of whatever Multics is many of". It doesn't have anything to do with whether the system is multi-user or not. Unix is most definitely a multi-user system. The old style permissions are definitely becoming a problem, but there are solutions such as ACLs, SELinux and beyond. They have just yet to be used in any great degree on the desktop Linuxes. Perhaps incidents like this will push Linux distributors to start using these technologies. BTW, for your little problem, just make sure you are in the disk group and everything will work. That's the whole point of why it is set that way...so that only users who are in that group can access the device (or root), and users outside of the group can't. Admittedly, it probably shouldn't be disk. That's a udev problem, but that can be fixed in a config file, which sets permissions and ownership for device nodes.

Re:Linux security

[TheRaven64]

Rather than setting xsane as setuid, couldn't you add a line to your init script that sets the group of the scanner device to a 'scanner users' group, and add any users who were meant to be able to use the scanner to this group? Or setgid the xsane program into this group and not have any users in it, so anyone can access the scanner but only if they use xsane?

There are very few programs that need to be setuid root (su, sudo). Most others should be using setgid and sensible device permissions.

Re:Linux security

[include($dysmas)]

you shoot .... you miss.

in the paragraph above the one linked : "Multiplexed Information and Computing Service"

Re:Linux security

[tinkerghost]

Unix security is just not up to today's desktop hardware with scanners, usb stick and whatever else. The inflexible root-centred security system is no good for hot-plugin.

Just because you've never bothered to pay attention to it & figure out how it is supposed to work, doesn't mean it's outdated or of poor quality. I have worked with administrators that don't know how to use groups properly, and they bitch & moan that nothing works right. With 10 minutes of resetting permissions & updating groups, I can fix 4 hours of 'fixing'. If you set them up correctly & maintain them, groups solve 90% of your problems with security.

The key is having a plan & putting the effort into maintaining groups properly. One place I worked wouldn't let IT remove old user accounts when someone left - they would give the new person their own account & then the UN/PW of all the people that had the job before them so they could "check the old files". What they needed was a group for the position, and then add/remove people from the group as needed. Hell they have email addresses for people who quit 6 years ago - actively being checked as independant accounts instead of being aliased to the person who has the posision.

Bluntly, it's a security nightmare that could be solved with some propper planning & an understanding of the actual security model the system uses.

Re:Linux security

[FireFury03]

Rather than setting xsane as setuid, couldn't you add a line to your init script that sets the group of the scanner device to a 'scanner users' group

That would be the incorrect way of setting device permissions. Device permissions should be set in udev (it has been like this for several years now since the static /dev filesystem was more or less abolished).

Re:Linux security

[innocent_white_lamb]

That depends. The proper way to do this on Fedora is through console.perms

Without knowing much than what is in the article..

[Tanuki64]

...I would not call this a mere bug. This was an intentional attempt to create a backdoor. Come on, who believes that a very specific driver of all things changes the permissions of a very unspecific program like OpenOffice? Something like that does not happen by accident.

Ok, I might be wrong with my accusation, but in this case I'd say I don't have to prove it, but Samsung has to prove its innocence by making public in details how exactly it came to this 'bug'.

I agree, BUT

[PetriBORG]

I agree with what you said, BUT...

Stop with your lame "thousand eyes" theory. Apparently those thousand eyes couldn't see a permissions change on their own systems. This is uncalled for, because as can be see on the ubuntu forums you can clearly see it was the "thousand eyes" reality that caught this problem in the first place and found the solution to remove parts from the install script.

wrap_setuid_third_party_application xsane
wrap_setuid_third_party_application xscanimage
wrap_setuid_ooo_application soffice
wrap_setuid_ooo_application swriter
wrap_setuid_ooo_application simpress
wrap_setuid_ooo_application scalc
And the content of the function for suid-making functions etc. So I have to disagree with you there.

I also agree with you though that linux distros should be automatically building in some sort of tripwire type setup to protect important system segments from scripts that are like this.

Re:I agree, BUT

[TheRaven64]

I also agree with you though that linux distros should be automatically building in some sort of tripwire type setup to protect important system segments from scripts that are like this. OpenBSD emails root every night with the results of the daily insecurity check, if it finds anything. One of the things it looks for is new setuid-root binaries. If this had been OpenBSD, then it would have been caught within 24 hours of being installed. I'm surprised Linux distributions don't include something similar already.

Re:I agree, BUT

[plague3106]

The post you linked to is only three days old. I wonder how long the drivers have been changing permissions. Likely longer than three days, probably for quite some time.

Your last statement though reminds me, the program which I spoke of in my previous post was actually called Tripwire, and its been bundled with Redhat for quite some time now. Well, at least the last version of Redhat / Mandriva that I used did. Perhaps they've since removed it.

So, such a package does exist (I already knew that, I wasn't being facesous), it just seems no one user it.

Re:I agree, BUT

[PetriBORG]

I also agree with you though that linux distros should be automatically building in some sort of tripwire type setup to protect important system segments from scripts that are like this. OpenBSD emails root every night with the results of the daily insecurity check, if it finds anything. One of the things it looks for is new setuid-root binaries. If this had been OpenBSD, then it would have been caught within 24 hours of being installed. I'm surprised Linux distributions don't include something similar already.

By default, I don't believe any of the mainstream ones do, or I am unaware of any. I absolutely think that Linux needs to be adopting a lot more secure settings and things to ensure that it doesn't turn into another windows box.

I suspect though that what the computer industry needs in general is a more user friendly model, a method to make security easier and transparent and thus understandable to the general user. A lot of that comes with by the computer setting up more secure default settings that still allow the user to do their work. Yet don't do the "allow or deny" crap that Vista does.

Re:I agree, BUT

[MrNemesis]

I also agree with you though that linux distros should be automatically building in some sort of tripwire type setup to protect important system segments from scripts that are like this

"This inst_samsng_drv.sh wants to change entries in /bin, /usr/bin and /usr/lib. Cancel or Allow?" ;)

I'm probably in the minority of desktop Linux users who has a reasonably comprehensive log/file scanning setup; AFAICR chkrootkit and rkhunter both have checks for suid programs, and I'd love to see both of these apps installed and run by default (say, on shutdown) and generate a desktop alert of some description.

I still don't think that'd do much to stem this sort of problem though; if people run an installer, they're expecting it to be modifying certain files, and most desktop users of the fabled future aren't going to have the first idea of what changes should and shouldn't be being made.

As an aside, is there any echnical reason that Samsung can't provide the drivers as binary blobs and leave the packaging/installation to someone more competent? Heck, paying a Debian package maintainer $200 to do it would have generated a better package that'd be able to be used/adapted by practically every distro out there and would have avoided this PR-debacle-in-waiting.

Re:I agree, BUT

[ajs318]

I suspect though that what the computer industry needs in general is a more user friendly model, a method to make security easier and transparent and thus understandable to the general user. A lot of that comes with by the computer setting up more secure default settings that still allow the user to do their work. Yet don't do the "allow or deny" crap that Vista does.

The only thing that will accomplish the effect you desire is a law demanding that every computer user has the right to view the Source Code of every program running on their system, or show it to an independent expert -- even if they don't have the right to make and pass on unlimited copies.

Keeping the Source Code secret from users is, to put it bluntly, a cunt's trick.

Re:I agree, BUT

[Megaweapon]

So, such a package does exist (I already knew that, I wasn't being facesous), it just seems no one user it.

Tripwire is mandatory in my shop (and checked daily), so I would have noticed. Then again I wouldn't be running such crap equipment that required such crap drivers.

Re:I agree, BUT

[cortana]

Well, it may protect against idiots and accidents, but if someone wanted to make something setuid for malicious purposes they could just alter the cron job that does the scanning. Or fork and leave something running in the background that would change the file permissions back to what they were before the cron job runs and restore the setuid bit after it completes...

Re:I agree, BUT

[FireFury03]

OpenBSD emails root every night with the results of the daily insecurity check, if it finds anything. One of the things it looks for is new setuid-root binaries. If this had been OpenBSD, then it would have been caught within 24 hours of being installed. I'm surprised Linux distributions don't include something similar already.

My experience of "things that email root every night with security checks" is that generally they trigger on so many false alarms that they are useless. Take logwatch for example - by default it trips regularly for completely innocuous stuff on all but the simplest of systems, and is relatively untweakable.

Re:I agree, BUT

[TheRaven64]

if someone wanted to make something setuid for malicious purposes they could just alter the cron job that does the scanning Unless you are running at securelevel > 0, and have the system immutable flag set on the script. In this case, even root can't modify it. Of course, your second attack would work, unless the insecurity report script was set to run with a random 0-24 hour delay at the start. This isn't done, but it seems sensible, so I might submit a patch.

Re:I agree, BUT

[RAMMS EIN]

``I'm surprised Linux distributions don't include something similar already.''

Why? Linux is much more about shiny features than about security. OpenBSD is the only OS that, in my opinion, takes security anywhere near seriously enough.

Regards,

A former OpenBSD user

Re:I agree, BUT

[somersault]

I fail to see how making the source open is going to educate the "general user" about privileges. I had hoped you were going to say that all users should be given a license before being allowed to operate a computer. Oh well..

Re:I agree, BUT

[blueskies]

is relatively untweakable.

Are you using the same logwatch the rest of us are using?

Re:I agree, BUT

[ajs318]

By itself, having Source Code on display isn't going to do much for the "general user". At best, more people will wake up to its importance. OTOH, it's still better to have a bigger minority who are in a position to do something with it -- read it, spot the nasties and fix them -- than a smaller minority who are in that position. More importantly, though, you have people with access to the Source Code who aren't under the influence of the vendor. It's possible -- not saying it's ever happened, but it could -- for a truly evil corporation knowingly to release defective software under the assumption that nobody would ever find out about it. If Source Code had to be made available, then this would effectively be impossible.

A licence for using a computer on the public Internet wouldn't be a bad idea in theory; but in practice, it would be about as enforcible as a licence for sex, and just as subject to abuse.

Re:I agree, BUT

[somersault]

Yeah I've thought about the license thing before, it is a bit of a fascist idea :p I think it would be largely enforcable though, and would cut down on a *lot* of the zombie botnet scum, but in reality I think if people are just educated a bit more about computer security in school then things will gradually improve over the next few decades. Just a shame so much bandwidth has to go to waste until then!

Flawed Design...

[krischik]

Only when the little bugger of an hotplug-manager changes the user id for the scanner device to the logged on user. Which still only gives one user access to the scanner. Have my Wife remote logged in and only one of us can use the scanner.

Unix security if just flawed and the flaw is called "root".

Martin

Re:Flawed Design...

[Anonymous Coward]

Maybe you should turn off the hotplug manager, or reconfigure it so it doesn't manage your scanner device? Why not set the scanner device to be owned by a group consisting of yourself and your wife? Then you could both use it, and neither of you would need to be root, and you wouldn't need any setuid binaries.

Re:Flawed Design...

[morgan_greywolf]

I'm going to reply to your post backwards, but you'll see why.

Unix security if just flawed and the flaw is called "root".

There is a fix for this flaw. It's called 'groups.'

Only when the little bugger of an hotplug-manager changes the user id for the scanner device to the logged on user. Which still only gives one user access to the scanner. Have my Wife remote logged in and only one of us can use the scanner.

This is distro-dependant. On Ubuntu, scanner access is controlled by groups. Want a user to be able to scan? You add them to the scanner group. You want someone to have access to burn CDs/DVDs? You add them to the cdrom group. If the scanner device is owned by any user, and owned by the group scanner, the permissions on the scanning device are set to group read/write, and both you and your wife are in the scanner group, then you both have access to the scanner. Try it yourself. Problem solved.

BTW--with SANE, the best way to have two people access the same scanner is via the saned network sharing mechanism, which allows other systems using xsane (or other sane front-end) to access the scanner over the network without having to remote login.

Re:Flawed Design...

[cortana]

Perhaps you should upgrade to a distro that is designed for use by multiple users:

$ lsusb -s 005:004
Bus 005 Device 004: ID 04a9:221c Canon, Inc.
 
$ ls -l /dev/bus/usb/005/004
crw-rw-r-- 1 root scanner 189, 515 2007-07-18 13:59 /dev/bus/usb/005/004

On Debian (and derived) systems this is done by udev.

Re:Flawed Design...

[drsmithy]

There is a fix for this flaw. It's called 'groups.'

Groups don't fix the flaw of a superuser. Not only are groups the wrong ballpark to do so, they're not even playing the same game.

Re:Flawed Design...

[GooberToo]

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.

There are of course some other areas which ACL's don't address but there are pre-existing mechanisms to address those as well. Well, on most modern Unix/Linux systems anyways. The model has survived for so long for simple reasons; it's effective, simple and covers the vast majority of situations. When complex requirements come into light, more complex solutions exist. Most people just don't know about them.

Re:Flawed Design...

[MyIS]

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:Flawed Design...

[DrSkwid]

Root is a design fault.

That's why the inventors of Unix took it back out again when they did their next OS

btw. it's dependent

Re:Flawed Design...

[dhasenan]

If groups aren't anything like a fix to the "flaw of a superuser", then ACLs, which are just groups defined on a per-file rather than a system-wide basis, are still not going to fix the flaw.

Re:Flawed Design...

[mgpeter]

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:Flawed Design...

[GooberToo]

I agree. Frankly, I've found very few situations where ACL or alternate solutions are even required...but they do exist. Smart use of permissions, groups, and masks typically address the need at hand. Tools such as sudo, PAM, and other suid wrappers help finish the complement. Heck, even SSH can be used to tie a key to a specific command or command line. Solutions are widely available, just most people are ignorant of the details and possible solutions.

I find most people that complain tend to be ignorant window users who find themselves forced to use Unix/Linux; so rather than learn, they complain.

Re:Flawed Design...

[armb]

> btw. it's dependent

It's more usually dependent, especially as an adjective, but dependant is valid too.
http://www.answers.com/dependant

Re:Without knowing much than what is in the articl

[krischik]

No, the problem come from the device driver for scanner devices which are raw scsi devices and therefore have some very restrictive security set.

The hot plug manager should change the user id to the logged in user - but that is not reliable. Personal experience in 50% of cased it stays on root so only root can scan.

And even if the user is changed - have 2nd user logged in and only one can scan.

Martin

Why did they do it?

[Anonymous Coward]

Probably, when you print using those applications, it starts a portion of the printer driver (userspace portions, maybe?) which somehow required root to run properly. Classic problem which *might* be avoided in most cases.

Tagged it mate

[Anonymous Coward]

Don't know about everyone else, but I tagged this: 'proprietarysoftwaresucks'

A fair surmisal of Samsung's almighty cock-up methinks. And remember: if they'd have freed the source in the first place, none of this would have ever happened.

English Non-Google'd Translation

[VE3OGG]

Hello,

After I installed the unified drivers for my Samsung printer/scanner, I had the unwelcome surprise of discovering that OpenOffice now opens as root, and not only that but did not ask for my password!

As a result, all documents I created were saved in the /root/ directory with super user rights. Practical and super secure!

I attempted to re-install .Xauthority without success.

The beast (the problem) is occuring under Ubuntu 7.04 under Gnome.

Thank You.

Bonjour,

Après avoir installé les drivers unifiés de Samsung pour gérer mon imprimante scanner, j'ai eu la très mauvaise surprise de constater que la suite openoffice s'ouvrait en root et ceci sans que me soit demandé le moindre mot de passe !!!

Du coup, les documents que je crée s'enregistrent dans le dossier /root/ avec des droits de super utilisateur. Pratique et super sécure !

A tout hasard j'ai réinitialisé le .Xauthority : aucun succès.

La bête est sous Ubuntu 7.04 et gnome. En attendant vote aide, je cherche et tente de résister au désespoir le plus sombre !

Merci

Re:Without knowing much than what is in the articl

[Anonymous Coward]

No, you are wrong and you are paranoid. Take off the tinfoil hat for a second.

You have a company, that has no experience writing drivers for UNIX operating systems, an operating system whose printing subsystem absolutely blows in all respects, and an office suite that also blows in all respects. The goal is to mix them all together and try to get something that works every time with no intervention from the user.

Guess what, make the program run as root because everything else on the system varies between distributions and you can't rely on a single thing (except the root account working), there's no good way to handle it. It's a dirty dirty dirty hack, but it works. Oh, except that it breaks the profiles of people and OO defaults to /root.

It's totally the wrong solution, but it's definitely not malicious.

Time to Get Heavy

[ajs318]

The proprietary driver fiasco has gone on far too long. It's time to stand up and say Enough Already!

Let's all get writing to our elected representatives and demand that hardware manufacturers be obliged, by law, to provide detailed specifications which would enable a sufficiently-competent programmer to write a driver program enabling any of the features of their product to be used on any sufficiently-capable computer.

Failure to do this places the rightful owners of hardware at a disadvantage. They can only use it in conjunction with certain Operating Systems. They are restricted to using it as the manufacturer thought fit. If a driver has a programming flaw, the user's computer can be compromised. If the Operating System is updated in such a way as the driver no longer works, the user is at the mercy of the manufacturer to release a new version of the driver -- or else the hardware is unusable (or at best, usable only through a bodge involving multi-booting: at the boot prompt, type linux to be able to use the Internet, or linuxOLD to be able to print).

It's unfortunate, but this measure really needs to be brought in through legislation, because manufacturers will not do it voluntarily. There are two reasons: (1) they are paranoid of competitors {despite the fact that their competitors are busy reverse-engineering their products in secret while they reverse-engineer the competitors' products} and (2) they habitually lie through their back teeth in their advertising literature about the capabilities of their hardware, and such lies would be exposed with disclosure (e.g. a camera with a 2 megapixel image sensor, spitting out JPEG images interpolated up to 6 megapixels).

Re:Time to Get Heavy

[Anonymous Coward]

Are you trying to put Apple out of business?

Re:Time to Get Heavy

[Xeth]

+4, funny? Ouch. I guess we are a cynical bunch. Next up: The "-1, Pointless idealism" mod?

Re:Time to Get Heavy

[runderwo]

It's unfortunate, but this measure really needs to be brought in through legislation, because manufacturers will not do it voluntarily.

I challenge you to name one measure that manufacturers will not do voluntarily that has been brought in through legislation, in the last 25 years. I don't think Congress has the teeth to regulate businesses without their consent anymore...

Re:Time to Get Heavy

[nomadic]

I challenge you to name one measure that manufacturers will not do voluntarily that has been brought in through legislation, in the last 25 years.

Nutritional labels.

Re:Time to Get Heavy

[Znort]

First of all, don't write once, write many times to your representatives. At best, any response will take time, so the next time you are out to by a new peripheral, choose one that has open source drivers or that have been validated by others (no real choice with graphic cards, yet). Money will always talk so buy cautiously and manufacturers will do anything to keep selling.

Safe Coding
Znort

Re:Time to Get Heavy

[sjames]

Non-OEM replacment parts for cars without voiding the warranty.

You said this earlier and ignored the answer

[Anonymous Coward]

Why did you say it again?

You can see with the XServer how to do it: the server is run as root, the direct hardware DRI access is set to "root:video" and any user who is part of the "Video" group and run DRI calls.

Re:Moronic Managers

[thegrassyknowl]

I deal with this kind of crap in embedded Linux installs daily. Managers and marketoids want to do all sorts of insanely stupid things under the guise of "making it easy for the customer to configure the device within a maximum of 5 minutes with no technical knowledge", etc.

In the mean time the fallout from all the insane things that "need" to be done is gaping security holes all over the place and a bunch of manager types saying 'but it doesn't matter, nobody will ever want to hack us'.

For the record I used to work for a company which built Internet-accessible security products. Whenever there was a breach it was always my fault even though I told them that enabling a particular service to the greater world was risky and would require constant attention by a qualified Linux admin and also require a regular mandatory update schedule and code reviews to continue some level of security. They never wanted to do the regular updates or code reviews because it was so costly and updates inconvenience the customer (I'm sure less than a r00ted box, but explain that to marketoids).

Suffice to say I quit that job and am starting another with a company that actually cares about security over customer friendliness (and cares about their employees at least as much as their profit margin).

Blown out of proportion?

[Jerry]

Here is a posting to the Ubuntu forum that is SEVEN MONTHS old and refers to postings A YEAR OLD!

Printer drivers need to be installed with world execute permissions so that all users on the system can access the printer. The Samsung hacker's method of doing this, converting them to 4755 bin files and setting the original name as a link to the bin files, is one way of doing that -- IF his "unwrap" function had worked properly. That's the bug. Listed in the posting are files whose permissions need to be modified after the driver is installed.

#1
Old January 18th, 2007
tweedledee tweedledee is online now
Way Too Much Ubuntu

Join Date: Dec 2006
Beans: 252
Ubuntu 7.04 Feisty Fawn User
HOWTO Install Samsung Unified Printer Driver
I had a fair amount of trouble initially getting my Samsung printer installed completely, but I finally have it all done, so here's a mini-guide for those who might benefit.

NOTE: for the last few months, the Samsung website has been utilizing some buggy Flash code that will crash many (all?) Linux browsers that have Flash installed - hopefully they will fix this soon, but they don't seem in any hurry. Either use a secondary browser that does not have the Flash plugin installed (e.g., if you mainly use Firefox, you could use Epiphany (Gnome) or Konqueror (KDE)) or download the drivers via another computer/OS. Alternatively, again if you use Firefox, you can install the "flashblock" extension, usually this prevents the crash (and is useful for many of the other websites that have been appearing recently causing the same behavior, although it's not 100% successful).

EDIT: The newest (as of this writing) driver from Samsung (20070324...) appears to solve some of the mfp/xsane issues, but also appears to missing a couple of library files. See post #23 for details. Also see posts #27-29 for details on ...plc errors and solutions.
Post #35 suggets the 200704.... drivers have resolved this issue, so this may now be irrelevant.

First, a disclaimer: much of the information I used came from this thread: http://www.ubuntuforums.org/showthread.php?t=28774 7. Another good source of information is http://www.linuxprinting.org./ Finally, I did this using the 20060719... and 20070125.... drivers; newer (or older) drivers may require some tweaks. Also, especially if you have a monochrome, non-duplexing, non-multifunction printer, you very well may have success with a generic post-script printer as a driver, without having to install the Samsung drivers. Also note that for my printer, pretty much all functions except duplex control worked even if I skipped steps 2-4 below (i.e., don't install the driver, only the relevant .ppd file) - which also has the advantage of not needing to fix xsane (additional step 2).

This works for my CLP-550; similar steps seem to work for other Samsung printers not supported out-of-the-box with the drivers available in a fresh Ubuntu install. This is NOT a multi-function, multi-functions may require additional steps (but are discussed in other threads, a quick search should bring them up). Posts below from other users have reported sucess (sometimes with a couple of small modifications) with: ML-2510 (# 5, 14, 16, 26), ML-2510/XEU (# 18 ), ML-2571n (# 12), SCX-4200 (# 10), SCX-4521F (# 11), CLP-300 (# 35).

1. Download and untar the driver from Samsung's website; for this example I will assume you untar it to ~.
2. Open a terminal and navigate to ~/cdroot/Linux. I had to "chmod +w install.sh" to give write permissions, but that may be unusual. Edit install.sh as follows:
a: change the first line from "#! /bin/sh" to "#! /bin/bash" (without the quotes)
b (possibly not needed): change the line that includes "guiinstall.bin" (search for it, it's around line 1277) to eliminate the ".bin" (i.e

Re:Blown out of proportion?

[Error27]

This is a dailywtf qaulity style bug. I think that's the point of the article.

It also messes with the lpr command

[jim9000]

I have a Samsung ML-2251N printer and the installer also replaces the standard lpr command by symlinking it to a script called slpr, which brings up a windows-like print GUI when you try to print things. This is highly annoying as it doesn't behave exactly like lpr and requires a GUI. It may also be SUID as well.

You can remove all of the SUID crap and point /usr/bin/lpr back to the right place. The proprietary driver still works and is much more secure. It prints faster with the Samsung driver than with the open source PCL driver. One day I might add true PostScript capabilities to it to try to work around both issues.

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.

Clue on what not to buy

[nbahi15]

Any printer that requires more than a PPD and CUPS to operate is suspect.

Re:Clue on what not to buy

[cianduffy]

...and Ghostscript, surely?

I've a Dell printer that requires a patched Ghostscript, normal CUPS, and a PPD... that not every distro carries - which is fun to handle.

Great!

[markov_chain]

It can join the good company of General Protection Fault, or Kernel Panic

Get a decent distro

[cortana]

Get a decent distro that uses udev to set the permissions of device files when they are created, as detailed http://it.slashdot.org/comments.pl?sid=251801&cid= 19899587

If "ls" is trojaned

[Anonymous Coward]

your data is worthless. It could be trojaned too. So you need to install all your OS, patch it and retrieve all your data.

If all you can write to is $HOME then you can trust "ls" isn't trojaned and you need to retrieve all your data.

So is it better to

a) reinstall your OS patch and retrieve all your data
or
b) retrieve all your data

?

You keep banging on about this "problem" when solving your complaint doesn't help the situation. You may be right in your complaint but it doesn't have an effect on the issue you claim the complaint is about.

You think $HOME needs protection. You complain that only non-$HOME directories are protected. Hos does not protecting non-$HOME directories help your $HOME directory be safer?

"Slashdot requires you to wait between each successful posting of a comment to allow everyone a fair chance at posting a comment.

It's been 17 minutes since you last successfully posted a comment"

holy shi....

[Sfing_ter]

Samsung makes printers? That people actually buy?

Re:holy shi....

[Chirs]

I've got a Samsung laser printer at home. It's a small-business model that was on for half price. It's rated for 150000 pages before any servicing is required, takes a ream of paper at once, prints 6000 pages on a toner cartridge, and prints text at 30 ppm.

I've had it for almost 2 years, and so far I haven't had any problems with it.

Re:holy shi....

[tweek]

You would be surprised. I dealt with a Samsung rep at a previous company and you would be surprised how much Samsung technology and parts are in OTHER printers.

Re:holy shi....

[Anonymous Coward]

I bought a Samsung laser printer for $70 at CompUSA last April to do my taxes. It was cheaper than buying ink for my inkjet. Printer works quite well! No problems so far.

Re:holy shi....

[Anonymous Coward]

I've got a Samsung ML-2010 that is so vastly better than any other printer I've ever had (about seven: two Epsons, various HPs including the much vaunted DJ500) it almost makes me *weep*.

I named it Sweetie, after Frederik Pohl's old programmable calculator. And I'm not one to name things.

Re:holy shi....

[u38cg]

Yup. I had a ML-1210 that ran till I dropped it down a flight of stairs (it still printed blank pages afterwards), then replaced with a ML1610 which is a stripped down 1210. Perfectly functional laser printer, cost £59.99 (about $120) and hasn't had a new toner ~18 months later. Oh and it's running this crap...Samsung's UK helpdesk is now closed but I will be hitting them up in the morning.

May not be that big a problem

[vtcodger]

This may not be that big a problem -- at least for the Samsung color laser printers. Why not? Because the Linux installer for those printers seems to be unusable on many new Linuxes. The installer is dynamically linked to libraries that are no longer used and it apparently doesn't install properly when newer versions of the libraries are linked. It took me a number of days to get a CLP-300N printer working with the Samsung drivers. There is an alternate open source driver called foo2qpdl that does work.

My somewhat rambling notes on this subject are on the internet at http://donaldkenney.110mb.com/LPRINTER.HTM. I plan to clean them up and correct the consistent misspelling of kubuntu ... someday. I posted the notes because I couldn't find any explanation anywhere of the Samsung message 'unable to find a suitable printer' or any thoughts on what to do about it other than to return the printer to the store.

Re:May not be that big a problem

[the eric conspiracy]

For Linux I try to stick to Postscript printers. They just seem to work better and there usually aren't any driver problems when all you need is a ppd file.

Re:May not be that big a problem

[vtcodger]

***For Linux I try to stick to Postscript printers. They just seem to work better and there usually aren't any driver problems when all you need is a ppd file.***

I've had nothing but bad experiences in my limited experience with Postscript. Used to be slow. Still is for all I know. Hangs sometimes. Not available on inexpensive printers that users prefer because they don't want to walk down the hall to get their small printouts. I know that it's heresy, but I think PCL works as well on high end printers and is the only game in town for low end. ... Maybe for serious graphics and publishing Postscript is superior, but for home and most office use, Postscript looks to me to be a slowly dying option. I looked for recent market share data for PCL vs Postscript vs both, but couldn't find any. It was 3:1 PCL a decade ago. I'd think it would be worse now thanks to the ubiquitous PCL only HP Deskjets.

In any case it's probably a moot point. I don't think there is an inexpensive color laser printer that comes with Postscript. Our CLP-300 is (we hope) a final solution to struggling with #$@)$ ink cartridges for occasional color printouts. Invariably when we wanted to do a color printout, one or more color jets on every inkjet printer in the house would be plugged. Colors from the CLP-300 aren't as vivid as inkjets, but anything that means that I never have to try to resuscitate a nearly new inkjet cartridge again is a winner in my book.

Re:May not be that big a problem

[the eric conspiracy]

I have a Samsung CLP-550q that I paid about $330 for. I bought an HP Jet Direct on EBay for abut $40. Result: networked color laser duplex Postscript printer. While I don't like walking down the hall, for this price you don't need a lot of users to justify it over some crappy desktop inkjet.

As far as PCL goes, for this printer I don't use it. For printing from Windows I use the Samsung drivers which use the Samsung proprietary language, and for Linux I use Postscript.

Plug-And-Pray

[krischik]

Maybe you should turn off the hotplug manager, or reconfigure it so it doesn't manage your scanner device? If only I know how to. I am with Linux for a very long time and I can configure/tune almost everything but hot-plug, auto-mount and and all the other plug-and-pray stuff are beyond me. With the scanner being only a minor nuisance. More upsetting is are FAT32 USB drives getting mounted with the wrong options.

I tried to read myself into it but is is so complicated. So somehow I understand Samsung in using the suid sledge hammer to get it working.

Why not set the scanner device to be owned by a group consisting of yourself and your wife? Then you could both use it, and neither of you would need to be root, and you wouldn't need any setuid binaries. Indeed - that's the way I did it before plug-and-play arrived on Linux. However - the old system had a problem as well: With each system update and sometimes in between the access right in /dev where "secured". Also, one thing plug-and-play does do is loading the proper kernel modules for you. In those times I often had to reboot with the scanner switched on in order to get things working.

Martin

Re:Plug-And-Pray

[Anonymous Coward]

Friendly Advice:

1) Burn a copy of your home directories to a CD.

2) Reinstall Linux. Skip the Samsung drivers.

3) If you're trying to configure a printer, use Splix.

4) If you're trying to configure a scanner, plug it in, boot Linux, type "sane-find-scanner". If your scanner isn't supported under Linux, pick up a Canon N650u on Ebay for fifteen bucks. I do a webcomic, and that's the scanner I use. Very nice!

Never trust third party packages

[cortana]

This is only an issue because Windows has moronised people into expecting that they must download an unverified, untrusted executable from a third party web site and execute it with full system privileges.

Thanks, Microsoft!

Stick with your distribution's official package archive and this simply won't happen.

Re:Never trust third party packages

[TheLink]

Yeah, and you might have to stick with your distribution's officially suported hardware.

That sounds a bit like Apple eh?

The windows way is where you have tons of different sorts of hardware with the corresponding crappy drivers/software that may or may not have security problems like these.

Linux will be somewhere in between, but as it gains in popularity, if the "desktop security" architecture isn't changed, these sort of things will happen on a more regular basis.

There's probably not much you can do with respect to drivers as they need system level access and it may be hard to predict what sort of access they need. BUT, for the other sort of 3rd party apps, I think it should be fairly easy to restrict the access they get to a few categories and thus have a manageable set of standard sandbox templates and standard installation APIs and procedures for running or installing random 3rd party apps reasonably safely.

For example: only certain types of apps need access to your microphone and network. And very few of those will require full read (or even write) access to your home directory, or even ~/Documents directory or ~/Maildir. At most they should only be sandboxed to ~/Programs/$Progname/ but able to be linked to the usual libs.

But I doubt a Linux distro could pull this off successfully.

Maybe Apple might be able to force developers to do that sort of thing. After all they've had great success over the years getting 3rd party devs to do things "The Apple Way".

Re:Never trust third party packages

[cortana]

Yeah, and you might have to stick with your distribution's officially supported hardware.

That sounds a bit like Apple eh? I must disagree here. If there is a third party driver that is not packaged for your distribution you are free to package it, and propose it for review and eventual inclusion. This process would have caught this horrible workaround... try posting an RFS to debian-mentors for a package that changes the permissions of another package's files and see if you get a favourable response... ;)

There's probably not much you can do with respect to drivers as they need system level access and it may be hard to predict what sort of access they need. BUT, for the other sort of 3rd party apps, I think it should be fairly easy to restrict the access they get to a few categories and thus have a manageable set of standard sandbox templates and standard installation APIs and procedures for running or installing random 3rd party apps reasonably safely. Well, that is kind-of what the Debian packaging process does. It would have been possible to get this driver into non-free, as long as Debian would have been granted permission to distribute it; the actual security problem here is not the driver itself, but the setup script, which would have been scrapped and replaced by something written by the package maintainer, who is supposed to know what they are doing.

For example: only certain types of apps need access to your microphone and network. And very few of those will require full read (or even write) access to your home directory, or even ~/Documents directory or ~/Maildir. At most they should only be sandboxed to ~/Programs/$Progname/ but able to be linked to the usual libs. You're basically describing SELinux. I hope that, some day, it takes off. But I don't think it will work for this case. Again, we need to look at the security problem being discussed here. Samsung included code in their driver's installation script that made programs that need to use the scanner be setuid root. Why did they do this in the first place? Because it was easier for them to bypass whatever security restrictions the local system already had in place, than it was to work with the local system and grant the right users access to the scanner.

So basically, even with SELinux, either the script would have called the policy-manipulating commands with the goal of allowing itself permission to set the other programs setuid root; or it would have failed, and the user would have been unable to use their scanner (at least, without adding their user to the scanner group, or doing whatever one does to grant permission to the scanner devices on non-Debian distros).

Re:Never trust third party packages

[TheLink]

Actually when I say sandbox templates I don't mean SELinux.

It's the difference between "the ability to set fine grained controls" (SELinux) vs "default controls for various classes of apps" (sandbox templates).

See more here: http://slashdot.org/comments.pl?sid=251671&cid=198 97861

The bug is that it doesn't properly UN-SUID them.

[Varka]

The bug is that the driver actually tries to UN-suid the applications: unwrap_setuid_third_party_application xsane unwrap_setuid_third_party_application xscanimage wrap_setuid_ooo_application soffice un wrap_setuid_ooo_application swriter un wrap_setuid_ooo_application simpress un wrap_setuid_ooo_application scalc un But they screwed up the oo unwrap part. The "un" should be BEFORE the "wrap" on those lines. It suids the apps temporarily, and improperly un-suids them.

Privilege instead of root

[krischik]

Unix security if just flawed and the flaw is called "root".

There is a fix for this flaw. It's called 'groups.' No the fix is called:

SET Process /Privilege=(...)

Only that is a VMS command and not available on unix.

Apart from that: I am using SuSE which changes user id's in /dev on the fly - which I think is not a good idea.

Martin

Re:Privilege instead of root

[russotto]

In VMS, any user with SETPRIV is effectively the superuser. Linux made an attempt at more granular privileges like VMS (capabilities, IIRC), but it turned out badly and the remnants seem to be withering on the vine.

Re:Privilege instead of root

[morgan_greywolf]

Sounds like sudo/gksudo or super (which attempts eliminate some of the insecurities of sudo by only allowing specific commands to be run -- not that this can't be done with sudo).

Re:Privilege instead of root

[johnw]

I've come across this sort of cock-up in the past, in precisely that environment - VMS.

Developers would do their work on a development machine, and for their convenience would have the SETPRIV permission, and then for further convenience would put "set proc/priv=all" in their login script. They then forgot about this and went on to develop the software.

The problem came when they tried to deploy to a customer's system. There the same software would be expected to run with normal user privileges, or at least a known and documented list of extras. The developers would have no idea what privileges they needed and would do all sorts of nasty frigs to get things working.

This story has just the same smell about it. I'd put money on knowing what has happened - the developer did all his normal system usage as "root" and developed the driver on this assumption. Then when the time came to deploy it on a customer system it didn't work because of lack of privileges. To get it out the door someone then quickly made a list of all the programs which needed extra privileges and wrote a nasty script to give it to them all.

It's just common or garden incompetence. All too common unfortunately. (Can anyone say "VIA video drivers"?)

John

Re:Privilege instead of root

[krischik]

:-)

Of course almost all Windows software is written that way. After all Windows has a very similar system of privileges. Only on Window - for your convenience - if you join the administrator group you get an implicit "set proc/priv=all" - no actually "SET JOB /Privilege=All" which is even worse.

Martin

Re:Privilege instead of root

[Anonymous Coward]

The original setpriv in VMS was seriously broken. We had people creating trojan programs that turn on all privileges and then did naughty stuff because they knew one of the admistrators liked to snoop around and run people's programs.
We eventually made a special program that would add privileges to people that needed a password to work rather than using the normal mechanism.
Another cute misfeature of the setpriv system was that mail used to call foreign terminal handlers that were selectable by end users. They would drop privileges, but the interesting foreign terminal handlers that we used, would turn them back on and then make use of the physical I/O privilege.

Re:Privilege instead of root

[krischik]

Yes and no. Spot the difference:


SET Process /Privilege=ReadAll
backup Old_Data
SET Process /Privilege=ByPass
deltree Old_Data
SET Process /Privilege=(NoByPass,NoReadAll)



sudo backup Old_Data
sudo rm -rf Old_Data


Ok, Unix is - as always - a lot less typing. But the real difference is that backup does not run with full root privileges on vms. Neither does deltree - it only is allowed to bypass ACL's - it could not mount a new i.E. a file system.

Martin

PS: if you have not got deltree for your VMS system I feel sorry for you.

Re:Privilege instead of root

[Anonymous Coward]

- it is possible to disable access to the root account.
- Linux implements POSIX capabilities since kernel 2.2

see the file capfaq-0.2.txt for details: http://www.filewatcher.com/m/capfaq-0.2.txt.11907. 0.0.html (list of mirrors hosting the file)

Re:Without knowing much than what is in the articl

[jimicus]

Never attribute to malice that which can be adequately explained by stupidity.

Granted, that means attributing a pretty stunning level of stupidity to Samsung's driver engineers, but no more than I've seen from some drivers in Windows.

Re:Without knowing much than what is in the articl

[east coast]

This was an intentional attempt to create a backdoor.

So when this same type of thing happens in Windows it's that Windows coders are inept but when the same happens in Linux it's because of a conspiracy? Please.

The Linux community better be damn well ready for when this becomes commonplace as more people use Linux. I don't expect it as much from real vendors but it's going to happen more from the likes of amateur coders and malware producers.

Too many have fallen pray to the myth that Linux isn't going to have some of the same issues that Windows has with these areas in software. This incident alone shows that Linux will not be immune to those who don't care enough, don't know enough or are willing enough to sacrifice system security for whatever reasons.

Re:Without knowing much than what is in the articl

[Anonymous Coward]

I think the permissions of OpenOffice.org are changed because there is a scanner interface in Writer, Draw, and Impress (Insert --> Picture --> Scan). I suppose that the Samsung driver author, who seems not to understand *NIX group permissions, wanted users to be able to scan directly into OOo.

strict tree

[krischik]

Sometimes I which I could attach one answer to two parents - but that does not work on /.

You can see with the XServer how to do it: the server is run as root, the direct hardware DRI access is set to "root:video" and any user who is part of the "Video" group and run DRI calls. Yes and printer usually work the same way. Only the sane guys did it different. Ok there is now saned but saned did not replace sane and is not installed by default.

Martin

In what way doesn't that solve the issue?

[Anonymous Coward]

scanner run as scanner:scanner. Users wanting to address the scanner must be in the scanner group, but there is no login for user scanner.

How doesn't that solve the problem?

sane in general

[krischik]

I don't have a Samsung printer/scanner. My point is that I can almost understand Samsung because of all the trouble I had in the past 8 years or so that I use a scanner (epson btw) with Linux.

There where always to problem zones with sane:

1) Kernel module (scsi/usb/sane) not loaded - solution: reboot/reconfigure.
2) Access right not set - solution "su -l".

Yes, it got better over time - and it almost works now (at least for the user logged on to tty7).

Martin

Re:sane in general

[fatphil]

"""
Kernel module (scsi/usb/sane) not loaded - solution: reboot/reconfigure.
"""
?!?!?!??

If the problem is that the kernel module is not loaded, then insmod it.
No reconfiguring, no rebooting, just a simple insmod or modprobe.

That's why it's a _module_, you see.

What's the purpose of this [expletive deleted]?

[argent]

It suids the apps temporarily, and improperly un-suids them.

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:What's the purpose of this [expletive deleted]?

[Varka]

Actually, I was wrong.
The original post was garbled due to my lack of previewing, but it only unwraps the binaries when you're UNINSTALLING the drivers.

Re:What's the purpose of this [expletive deleted]?

[Obsid]

Which also means that you will have to uninstall the driver first if you plan to remove OpenOffice or something.

If it wasn't a management decision to start with

[Moraelin]

I wouldn't be too surprised if something like this was a management decision to start with. Someone figured out they'd save some money on tech support calls, for example, if the users don't have to keep calling with stuff like "why does this ask for a password when I want to change the printer?" and "does your driver have a virus? my grandson said I should beware stuff that asks for a password" (for bonus points: "... and he didn't tell me the password anyway. Can I still use the printer?") and the like. Don't underestimate the kind of dumb decisions that get taken in the name of cost cutting.

And that includes the fact that it probably wasn't a programmer/architect that made the installer anyway. The drive for cost cutting includes the idea of giving each job to the lowest wage monkey who can possibly do it. So it's not entirely unheard of to offload to the cheapest interns or even to underused non-technical members of the team stuff like making an installer or writing the test cases.

In which case probably some under-paid and under-skilled monkey got the honour of figuring out how to install that stuff in Linux. These aren't typically the kind of guys you'd ask to do a security analysis and design, and they're not given ample times and funds for research either. So he'll google if he has a problem (like how to make some nice config dialog modify a file that was installed as writable by root only), and take the first thing that sorta looks like a solution.

Plus a few other such fun ways to fuck up in the name of keeping the costs down.

Mind you, I'm not saying this has to be what happened at Samsung. Just saying that I've seen that and worse happening in other places, so I wouldn't be too surprised.

Beware the beast!

[Anonymous Coward]

>
> La bête est sous Ubuntu 7.04 et gnome
>

Actually the beast (la bête) does not refer to the bug but to the computer. A better translation would thus be:

"The beast (computer) is under Ubuntu 7.04 and Gnome"

Now of course, the even better translation would be:

"The beast is running Ubuntu 7.04 and Gnome"

but it would not stay close to the original french text...

Yeah, bash me! I'm french!

AC

Re:Beware the beast!

[Anonymous Coward]

Thanks for the clarification! I thought it was a funny translation, but I wasn't sure.

hahaha should have used windows

[Anonymous Coward]

that's the kind of post slashdot usually gets when a windows bug is reported. so here goes...

HAHAHAHA you lame ass kids should learn to use a real O/S like Vista.

Re:hahaha should have used windows

[Obsid]

you lame ass kids should learn to use a real O/S like Vista.

Still have to make it run first :-)

Noticed this with CLP-510 last year

[equivocal]

Bought a CLP-510 (cheap for a reason) last year only and got some experience with Samsung's linux driver because it supports only some proprietary Samsung format. The Samsung driver prints by setting up a filter chain which

1. converts everything to postscript, if not already (ghostscript)
2. convert postscript into an intermediate standard CMYK format (ghostscript again)
3. convert the intermediate format into a proprietary binary blob
4. write the blob to the printer device

Generating the binary blob uses a binary executable that is included with the driver package and is the only "secret sauce". Everything else is standard CUPS and related programs.

The SUID part comes from the Windowsification of the interface. They replace "lpr" with one that bring up a Windows-like printer config GUI. In, fact it, you can't print with it unless you're running X. The GUI writes the user's selections to the PPD in /etc/cups (which requires root permission) as well as to ~/.lpoptions. It also means that the next print user will start with the options selected by the previous user. Also annoying that duplexing (built-in) could not be controlled from software. I'm sure the Windows driver didn't have that problem.

In short order I replaced the 510 with a CLP-550 which supports postscript natively. I didn't bother with the Samsung driver, but when I found that the 550 didn't have enough memory to print a full-page graphic I extracted the needed components and ran the filter chain manually.

Re:Without knowing much than what is in the articl

[Tanuki64]

So when this same type of thing happens in Windows it's that Windows coders are inept but when the same happens in Linux it's because of a conspiracy? Please. If the Samsung coders are that inept, the deserve to be fired at once. This 'bug' is that severe that there is absotely no excuse.

The Linux community better be damn well ready for when this becomes commonplace as more people use Linux. I don't expect it as much from real vendors but it's going to happen more from the likes of amateur coders and malware producers. This is a bogus argument, which simply is not applicable in this case. If Linux gets more users, the percentage of those who install and execute everything the find will grow, but this has nothing to do with dangerous commercial, binary only software packages.

Too many have fallen pray to the myth that Linux isn't going to have some of the same issues that Windows has with these areas in software. Maybe too many, but not those who count. Every developer and every admin with normal average knowledge knows that Linux will have the same problems when companies spew their binary only junk around, which has to be installed as root. This is one reason why there is such a strong opposition against binary drivers in the kernel.

This incident alone shows that Linux will not be immune to those who don't care enough, don't know enough or are willing enough to sacrifice system security for whatever reasons. "Don't care enough, don't know enough". You make is sound as if a user was at fault here. What would have been the correct behaviour of a user who knows and cares except not to by Samsung hardware in this case?

Samsung

[ledow]

It's a shame that companies just aren't bothering any more. Samsung is certainly one company that doesnt "get" linux but at one point it wasn't doing too bad. The ML-4500 I have even has a little Tux on the box and some CUPS PPD's on the CD.

As another post says, any printer that needs much more than a PPD is one to steer clear of anyway. It does bug me especially with printers... there are buckets of supported printing protocols that work cross-platform and even cross-printer (Postscript, PCL, for example). Yeah, some of them were made by a particular company foisting their own protocol on people but for the most part they are documented, complete, simple to support and cross-platform.

My ML-4500 is an odd device - it's not Postscript, not PCL, it even needs a tweak to the PPD supplied on most websites (including what was linuxprinting.org) or the CD to strip out extraneous page feeds at the end of the job. But there's code, PPD's and some hint that they were trying to do stuff properly for the Linux user of the time (as an aside, the driver on the CD mentions Linux 2.2 - they weren't that many companies supporting Linux printing back then). And it works. Very well. Even over a NetportExpress, with simultaneous Linux/Windows users randomly printing to it.

And the toners for the ML-4500 are combined toner/drum but they come with a little cap that you pop off, dump some generic toner in and carry on perfectly - my first toner/drum lasted 5 years, approximately 20 refills (totalling about $30 in all) and then started to fade a little bit in certain areas (I kept the toner/drum and use it as my emergency backup). Brand new toner/drum on eBay - about $30. That's already on it's third refill.

It's almost as if there was one man on the design team for that model who had brains and mostly got his way - but at critical points, hurdles were introduced by others (e.g. proprietry protocol, combined toner/drum) and he tried his best to overcome them (by making an OS driver for it, by designing an easy-to-use toner cap that you could refill with just about any toner you had laying around etc.).

Naw.

[Almahtar]

If all you see is "security flaw ... something something ... Linux", you've missed an important chunk of the story. The problem is that Samsung's drivers were poorly coded and completely ignored the built in security mechanisms of a Linux system.

You still have to be root to install their drivers, so no this is not a problem with Linux's security.

Another important lesson we can draw from this is that the drivers in question are not open source. Sure, people get tired of open source users constantly griping "xxxx isn't open source! Crucify! Crucify!" but then something like this comes along and proves them right: if we had access to the source, we would have seen the security problem, fixed it, and shipped the changes back to Samsung free of charge. Samsung gets free development time, Samsung product users get better security. The only down is that Slashdot doesn't get to print a story about "security flaw ... something something ... Linux"

Re:Without knowing much than what is in the articl

[davidsyes]

/rant on

C'mon! Linux or Mac or windoze or whatever, you are NOT going to be allowed to deploy any actual or near-mainstream systems like operating systems and crypto without SOME men-in-black-like visit from some government agencies looking for quarterly crypto keys. They'll arrive in suits, with brief cases and dead-serious looks. Or, they'll fake their appearances or get them on-line. One way or another, the governments and numerous programmers are GOING to talk.

Security is an illusion unless YOU have no rosey filters blocking your vision. Now, how can I say this? Well, some years ago, I contracted at Lotus cc:Mail. I was returning from a bathroom trip, saw some guys in black suits, shades and holding brief cases. In the hall I joked to a managerial level person, "Who are THEY? Secret Service looking for quarterly security keys?" He shot back, "Don't EVER say that." He took me aside and told me that's EXACTLY what they are there for.

So, if Lotus did it in 1997/1998, you can bet Mshaft does, and so does McAffee. Why do you think they won't comment on whether or not they comply with government court orders? Most people are sheeple, and most of us aren't savvy or patient or disciplined to use even the most BASIC of encryption tools, wallets, etc. //rant off

Re:Without knowing much than what is in the articl

[sjames]

Agreed, it's not likely malice, but it is one of the more agressively stupid moves I have seen. All they had to do is chmod o+rw the scanner device. (or just tell the user and let them deal with it.).

They could have even been really cleaver and given a SANE developer a brain dump of the device specs and had a really nice driver written by a Linux expert for FREE!

Otherwise, they could have gotten tons of free advice from SANE developers on writing a suitable driver module.

If truly desperate, they could have even written a daemon to talk to the scanner and made THAT and only that suid root. If they static linked it, they wouldn't have to rely on anything at all that differs from distro to distro.

Re:Without knowing much than what is in the articl

[east coast]

"Don't care enough, don't know enough". You make is sound as if a user was at fault here.

My entire post deals with the coders, not the users.

This is a bogus argument, which simply is not applicable in this case. If Linux gets more users, the percentage of those who install and execute everything the find will grow, but this has nothing to do with dangerous commercial, binary only software packages.

Either you will admit that this is a strawman argument or you will have to absolve anyone who produces shoddy code that leaves the system open to outside influences in the future. Close source or open source should not make a difference with the security of a package and it certainly has no difference in the end result.

Maybe too many, but not those who count.

Oh, so you're saying that if a coder produces secure code and admins have secure systems using the Windows platform that the problems lay squarely on the shoulders of those who don't? That's fine but if that's the terms of how the OS will be judged in the face of malware and security vulnerabilities then we can simply scream "incompetence" at every Windows admin who didn't take care of business and left their system open to attack. If that's the way this is to be seen then, by your own standards, every OS is secure and well written. It's only the policies of the administration and users that are at fault.

Misnomer

[Anonymous Coward]

Uh, that is not a security hole. To call this a security hole is like calling a nuclear weapon an open door. Well yes, quite a few doorways will stay open when a nuke goes up anywhere near them.

s/Thomson/Thompson/

[sconeu]

And before the spelling police get to me, yeah, I misspelled Thompson's name.

Re:If it wasn't a management decision to start wit

[Obsid]

In which case probably some under-paid and under-skilled monkey got the honour of figuring out how to install that stuff in Linux. These aren't typically the kind of guys you'd ask to do a security analysis and design, and they're not given ample times and funds for research either.

That's what I tended to think as well, but we have to remember that this guy is working with people that wrote a kernel module and a function library (which is freaky, considering that we couldn't explore these binaries yet). My guess is that the guilty developer is either a trainee, or more likely a Windows developer that was pissed off being asked to write a Linux installer.

Unfortunately, more and more users seem to adopt the same schema : "how can I easily get root so I can work in peace". I've been asked once to tell how one can remove the root password on his machine. The guy knew that it was silly but we figured out that he actually was running gproftpd frequently, and was bored having to enter his password each time ! So he was about to run a FTP server on a machine with no password to the root account. Well ...

We had to explain that gproftpd doesn't forcibly need to be run as root, he doesn't forcibly need gproftpd to edit the proftpd config file, and that in fact, even the FTP daemon doesn't require to be run as root neither. The port 21 could eventually be claimed by xinetd.

Sadly, as a user reaches the limits of his own default environment, he usually assumes that the only way to circumvent the problem is to ascend to a user with an other level of power.

Can you say "Sony"?

[HiThere]

It's possible -- not saying it's ever happened, but it could -- for a truly evil corporation knowingly to release defective software under the assumption that nobody would ever find out about it.

OK, you don't have to. I'll say it for you. And name the corporation.
Sony knowingly to released defective software under the assumption that nobody would ever find out about it. When it was discovered an official spokesman said that it didn't matter because most people didn't know what a rootkit was.

Thanks, Samsung!

[Anonymous Coward]

Thanks, Samsung! Thanks for elegantly proving that binary drivers need to be replaced with open source ones.

Sounds like it's only for Ubuntu though...

[r_jensen11]

Or any other OS that allows a user to sudo any command. Honestly, that idea was a bad idea. Sudo is great for some things, but it needs to be kept in check. I guess that's what visudo is for, but how many of the people that get pitched Ubuntu know about visudo and limiting sudo powers?

Alternate Install Method

[umoto]

The problem is entirely in the installer, not the driver.

After I bought an SCX-4100 a couple of years ago, I ran the installer. I saw right away that most of what the installer did was worthless. It installed some GUI that was simply inferior to CUPS+KDE. That made me mad, so I undid the effects of the installer and dissected it until I figured out what actually needed to be installed to just print and scan. The list of files required turns out to be pretty simple, as long as you connect via USB instead of the parallel port:

- /usr/lib/cups/backend/mfp

- /usr/lib/cups/filter/rastertosamsung{pcl,spl,splc}

- /usr/lib/libmfp.so*

- /usr/share/ppd/Samsung/scx4100.ppd.gz

- /usr/lib/sane/libsane-smfp.so*

- /etc/sane.d/smfp.conf

You can get all of these files out of the driver package. None of them need to be installed suid root or anything out of the ordinary. All you need is read/write access to /dev/usb/lp0 (provided by the usblp kernel module), which you can usually gain by being a member of group "lp" or whatever your distribution calls it. Also, you need a line in /etc/sane.d/dll.conf that contains "smfp" so that sane will look for libsane-smfp.so .

Use the normal CUPS and SANE configuration steps to set it up. If you're lucky, you can use http://localhost:631/ , unless your distribution has disabled that method of configuration.

I blogged about this two years ago:

    http://hathawaymix.org/Weblog/2005-07-15

Note that many of the details have changed. This post is more correct.

Even though I've avoided the setuid security hole by installing by hand, I'm still very irritated that I have to use proprietary binaries with who knows how many security holes. Next time I'm not going to settle for a proprietary driver. Samsung advertised Linux support and that's half the reason I bought the printer, but I didn't realize the driver was proprietary until I already had the printer.

Samsung, if you read this, listen up: I am happy with the speed and reliability of this printer (I've gone through 5-6 reams of paper and only 1 cartridge), and I am happy that you have added x86_64 support. However, if I had known that I would spend about 40 hours messing with your drivers just to get the printer to work, I would have bought an HP printer instead, even if it cost twice as much. I will not be a repeat customer and I will not recommend any of your printers to anyone else unless you open your drivers.

That is entirely wrong

[Anonymous Coward]

That employee's manager is the one that should get fired.

Managers are responsible for that the skill levels (training, career paths, etc) are adequate. Managers also bear responsibility for quality as they are supposed to manage the processes for checking things and controlling. Manager should know his people and who is able to do what.

Management

[mistralol]

Sounds like a managment problem to me.

Software Guys: Its not ready
Managers: You showed me a working copy
Software Guys: But it has major security holes
Managers: Dont care ship it.