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).
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.
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.:)
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...
Unfortunately packages in contrib and non-free do not receive security updates, which is worse than if the packages did not exist in the first place: anyone running etch who installed the packages, expecting them to be updated is now screwed.
According to the security bug tracker, etch's java package is vulnerable to CVE-2007-2435, CVE-2007-2788, CVE-2007-2789, CVE-2007-3004, CVE-2007-3005 and CVE-2007-3503. No security updates are planned for any of these issues.
So say that the FSF vilifies other licenses is pure hyperbole! The page merely points out why certain licenses are (or are not) compatible with the GPL, and whether or not they are as good as the GPL at preserving the four freedoms.
What I don't understand is why slashdotters would give a fuck about locking out legit users. Slashdotters themselves are not legit users (the piracy rate among slashdotters wrt Windows must be around 98%[citation needed]), so why do they care about WGA or the like?
The issues with dynamically loaded modules it particularly important. For example, if your program's statically-linked copy of glibc tries to load an NSS module from a different version... BOOM! If you link to another library that an NSS module that you load is also linked to, but with a different version... BOOM! And so on. This doesn't apply only to glibc, it applies to any library that may load DSOs at runtime, for whatever reason. For example, gtk theme engines, gnome-vfs protocol handlers, gdk image format handlers, input modules...
Users can use sc, net, or the services console to disable a service.
If Google thinks that's too difficult then they are free to make their desktop search program offer to disable Microsoft's service at installation time.
And IME the regular user launches IE via the default browser entry on the start menu. Change that and they have no idea how to locate IE and launch it to change it back.
No, on Windows the 'default web browser' also handles http (and some other) links. It's perfectly possible for applications to trample all over the wishes of the user and take over the association if they want to.
But DRM does not stop the videos from being uploaded either. It is precicely as effective; that is to say, not at all.
Giving someone the ciphertext and the key that decrypts it is exactly the same as giving them the plaintext. It has to be, otherwise how could they watch the content?
None of them are fully free and open--there is always some combination of non-free, binary firmware and/or a regulatory compliance daemon of some kind involved.
The other great thing about git is how easy it is to sling changes around and reorder them and combine them. For instance let's say you add a file to your project as commit "A". Then you add some code that uses this file as commit "B". Then you fix a bug in the file as commit "C". So you have A-B-C. Now you'd like to combine A and C into a single patch A', and put B on top of it, like this: A'-B. In git, this is super-easy. I can think of two ways to do it off the top of my head. Mind sharing that? I'm new to git and don't see the easy way to do it.
Slashdot Mirror
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...
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).
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.
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
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.
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...
I'm sure $600 is a small part of Blendtec's marketing budget.
Unfortunately packages in contrib and non-free do not receive security updates, which is worse than if the packages did not exist in the first place: anyone running etch who installed the packages, expecting them to be updated is now screwed.
http://bugs.debian.org/431831
According to the security bug tracker, etch's java package is vulnerable to CVE-2007-2435, CVE-2007-2788, CVE-2007-2789, CVE-2007-3004, CVE-2007-3005 and CVE-2007-3503. No security updates are planned for any of these issues.
Wrong, wrong, wrong. :)
Besides, which implementations of Lisp and Java are we comparing the garbage collectors of?
So say that the FSF vilifies other licenses is pure hyperbole! The page merely points out why certain licenses are (or are not) compatible with the GPL, and whether or not they are as good as the GPL at preserving the four freedoms.
They broke lpadmin and the web interface? Ouch!
What I don't understand is why slashdotters would give a fuck about locking out legit users. Slashdotters themselves are not legit users (the piracy rate among slashdotters wrt Windows must be around 98%[citation needed]), so why do they care about WGA or the like?
Everyone considering linking statically to anything should read http://people.redhat.com/drepper/no_static_linking .html.
The issues with dynamically loaded modules it particularly important. For example, if your program's statically-linked copy of glibc tries to load an NSS module from a different version... BOOM! If you link to another library that an NSS module that you load is also linked to, but with a different version... BOOM! And so on. This doesn't apply only to glibc, it applies to any library that may load DSOs at runtime, for whatever reason. For example, gtk theme engines, gnome-vfs protocol handlers, gdk image format handlers, input modules...
NOTABUG.
Users can use sc, net, or the services console to disable a service.
If Google thinks that's too difficult then they are free to make their desktop search program offer to disable Microsoft's service at installation time.
And IME the regular user launches IE via the default browser entry on the start menu. Change that and they have no idea how to locate IE and launch it to change it back.
No, on Windows the 'default web browser' also handles http (and some other) links. It's perfectly possible for applications to trample all over the wishes of the user and take over the association if they want to.
I think I speak for most of us when I say that software that fiddles with unrelated preferences when it is installed can fuck right off.
Thank god that those of us on decent platforms never have to deal with this crap!
But DRM does not stop the videos from being uploaded either. It is precicely as effective; that is to say, not at all.
Giving someone the ciphertext and the key that decrypts it is exactly the same as giving them the plaintext. It has to be, otherwise how could they watch the content?
My god, how ever did the creative industry survive before the almighty Photoshop added support for 16 bit colour channels.
Try nemiver. Far from perfect yet, but very promising.
Forgive me but these drivers still seem to require non-free firmware.
None of them are fully free and open--there is always some combination of non-free, binary firmware and/or a regulatory compliance daemon of some kind involved.