This is one of the downsides of forcing everyone to _register_ just to report a bug. (The other downside is the tremendous pain in the user's butt.) If they only used a simple solution like Request Tracker or so.
Emphasis mine. The summary almost makes it sound like the researchers just used HIV as we know it... it's almost humorous to think that a doctor might say "The treatment was a success, you no longer have cancer... but..." "BUT WHAT?" "Well, we sorta had to inject you with the HIV in order to take care of it." Obviously this is not the case.
The article also said that they used the virus as a delivery vessel to inject genes of their own choice into the white cells. So not much to do with the real HIV. And ultimately not that "HIV cancels out cancer". Using virii to change genes seems to me as a "normal" thing to do, as it has been noted in press before.
I know what monoculture in security context is. Let me restate my opinion: presenting 10 or so choices of popular distro's is not going to render a significant difference from only 1 choice.
As for botnets or harvesting data: they are doing it. Run a honeypot and you'll get yourself an IRC based botnet in 2-3 days average. Faster than snail mail!
I don't see what you were trying to say about servers. Obviously, the user factor will vanish on a headless machine, but OTOH servers get usually reaped via buggy webapps. The OS role in this is relatively minor.
Your monoculture argument is wrong. From the dawn of times, linux exploits come tailored for the most common distrubutions and some are even intelligent enough to determine the environment at run time. Some can even adjust for non-standard parts replaced by the user. And they have a very good success rate indeed. The number of possible combinations for a typical linux server or workstation is not by a long shot high enough to pose any problem due to environment diversity.
You have a far better point than the other reply to my comment, but nevertheless...
Kernel or other patches are a reactive measure, not proactive such as micro kernel, sandboxing, mandatory access controls, and shifting drivers to userspace (of which linux has the least).
One of the pillars of good security, i.e. ex-post detection of malicious behavior, is completely missing from linux installations, and seemingly from the mentality of the linux community, whereas on windows it is the norm to have an "anti virus" software, which can be pretty efficient in detecting userspace threats and sometimes even stands some chance against kernelspace intrusions.
The point of being able to run a VM legally in linux is valid, but no wide-spread practical application of that is currently available. In fact there's a lot of fine security solutions for linux (unfortunatelly sans the kernel itself) but they all are brutally under-utilized. From that perspective linux desktop is only at the very beginning of the road towards security. I stand with my previous assessment that the lack of linux based malware is from its greater part caused by minimal interest on the part of the criminals.
And yes, when linux becomes so popular that it will attract malware enough, the plan to move to another less known OS is pretty good;-)
Somehow this has slipped into a linux distro debate. You guys assume that linux is somehow superior in security against botnets, but I don't see why would that be so. Linux browsers, flash, and other apps, are as crappy as on windows, and there is really no obstacle in making a botnet/spyware/... run on linux. In fact it's going to be a lot easier because all distros have things like perl or python. The only thing that protects linux from this is its tiny market share, but see android... linux based, thus uber secure, right, right?
The problem is the inability of consumers or managers to understand the 3 part rule. Speed, Quality, Cost, pick two.
This rule concerns external quality of the product - as perceived by the customer. The problem with bad code is the *internal* quality - which has impact on the "quotient" for the 3 part rule. The worse the internal quality, the smaller the overall pile from which you "pick two". Eventually with very bad code the development just grinds to a halt.
I think the best analogy for this is furniture.
Mennonites make great furniture. It takes a long time, and is very expensive. It is a craft, and they are craftsmen.
IKEA makes some pretty shitty furniture but is good enough for many applications. It is cheap, and fast.
Yeah and internal quality (bad code vs good code) would then be the tools with which the furniture is made. Poor shops would assembly every piece by hands of unexperienced workers, great shops just have experienced guys working on top grade machinery. Both poor and great shops can still do the "pick two" tradeoff although it is obvious how their overall productivity would compare. And thats the way it is with shitty code (bunch of cowboy coders working on a yesterday deadline) and great code (tests, refactoring, good planning, experienced people).
Yeah, I've been using Jitsi for some time now, it seems to "just work" for audio/video calls and desktop sharing. It works over xmpp (jabber), which is massive plus, and it supports encryption of transfers in quite easy way. It also crawls over NATs, albeit not as aggressively as skype.
35% of technology professionals said they would sacrifice up to 10% of their salaries for full-time telecommuting. The average tech pro was paid $79,384 last year, according to Dice's annual salary survey, which means a 10% pay cut is equivalent to $7,900 on average
Wrong calculation -- the average pay of the 35% who are willing may not be equal to the average of all tech pros. So the 10% cut might be far from the said figure.
Cost could be an issue but it's like $100 a year? Hardly a problem for anything but the most amateur of blogs.
It's not that. It's key distribution. Without that HTTPS is simply not secure. I'm surprised that TFA does not mention it. In fact, it talks nonsense. "Everyone knows HTTPS is more secure." Secure from what? Mosquitoes?
But the whole point of this discussion: What if there is a bug in the library that renders that *data*? All of a sudden, your data is no longer very data-y, and much more executable-y than you might have intended.
For reference, take a look at the (lengthy) list of bugs in any of the image processing libraries.
Well, bugs can be fixed. But if you make it a deliberate feature to recklessly run anything that comes into your computer then there's little hope.
It's ok to start playing the movie or load up a slide show of the photos, because all that is just data. What's not ok and where the autorun FAILS is the possibility to execute arbitrary software without user's consent or notice. The same distinction goes with HTML vs Javascript.
You don't get the point because you don't have my setup, nor did you pay attention to a key word: "graphical". Non-GUI access to my systems isn't nearly as damaging as GUI access to them. For example, if I accidentally leave a document on which I'm working on my desktop, it's not readily apparent via CLI, but you can see it plain as day if you logon graphically. I don't like to take the risk, so a password is a good extra step to provide that security.
What I said is universally applicable. Graphics does not matter. "A password" can be used on private key too. And "a password" will not help you against someone determined to do the damage if they already have access to your account. Unless this is some sort of protection from 9 year olds that is.
my screensaver crashes for some unknown reason from time to time so while
Crashed screen saver usually renders the X session unusable because it would make precautions so that if it crashed then it would not expose working desktop to anyone while you're taking your break. That is at least the old school ones do this, maybe the new fancy ones don't:[
My sshd_config has PasswordAuthentication = no. Nothing can login via ssh(not even 127.0.0.1) without the proper PK.
Then the documentation lies...
I do agree they should generate a new key upon install.....and they offer that as well. If you read a bit more there's a step in the setup that asks if you want to use the default key pair. If you answer "no", it'll generate one for you. Are you sure you used NX for any *real* period of time?
Yes I devoted some fair time to make it working. (I failed on the PK auth step.) I installed the open/free version from packages so there were no questions asked. Hey maybe I am wrong and all crap like this has already been fixed - good for you/them/whoever then. But back then I assure you it wasn't just any one thing that pissed me off, it was the whole concert of them.
I personally like the password because that means that someone can't get unchecked graphical access to my remote machines by simply catching me on a bathroom break with my screen unlocked. In your scenario it would only take a single click. Yes, they would have access to my laptop but I'd rather have at least a password between them and access to the remote systems I admin.
I don't get the point here. You leave your screen unlocked then I gain instant access to where ever you're currently logged on. Plus I can stick a neat backdoor to your user account to automagically hijack all your further sessions (if time allows, depending on the magnitude of bathroom service you're utilizing...)
So please leave your screen locked. (BTW even if you lock it I can stick a key sniffer to your keyboard and pwn you anyway.)
Anyway what you probably originally meant is that PK auth is passwordless. Well it can be used that way but you can also put a password on your private key. Then you have to type that password in order to auth. The key difference here is that neither the password nor the private key leaves your computer and the login is unrepeatable without possession of the private key. That's in contrast to classic password auth where the pw is sent to the server where it can be sniffed and re-used. So what I meant in my original post is that in 2010 there is really no reason to use oldschool insecure auth methods.
Also, I don't think that you have the NX login sequence entirely correct because while the first part seems accurate, I can safely say that NX can NOT be spawning a second ssh session using my password because passwords are forbidden in ssh by policy on my system, so it'd have to be using my PK, or doing some other form of login.
Okay my experience with NX is about 18 months old and on behalf of this discussion I re-checked their docs today. It seems there is another way, that is using an internal database of users. The relevant source is http://www.nomachine.com/documents/admin-guide.php section 4. So either you're using that option or you should really re-check your SSH logs and config;-)
I don't ever remember being encouraged to keep the same public key for NX but I can safely say that my setup uses my own PK.
Now I can't find the reference but I swear I saw a paragraph saying something like if you replace the keys then out of box installs will not connect blah blah. Yeah I hear you say "big deal" but ffs this is about serious loss of security so there should never be a default key thus negating the necessity for mentioning "replacing the default key" somewhere in the manual. The keys should be simply generated at install time, with a message popping out "give this [public key content] to any Joe Schmoe you want to access that server of yours".
And just to let anyone know who might be interested in setting up RSA PK authentication with NX, you have to use NoMachines node/server/client from their site, the FreeNX/OpenNX only do DSA.
Sounds weird to me, why the heck would that be so? Both use the same ssh, which supports both.
the NX login requires a password regardless, I assume for security measures
Ouch. Getting your password transferred to & used at arbitrary locations is hardly more secure than the challenge/response PK schema in which your secrets never leave your computer.
IMO the reasons behind this are merely laziness/incompetence on top of bad design.
I personally am cool with that
I am not. First of all it is un-secure to enter your password somewhere without really having control of where it goes.
Second, it is a pain in the ass. Even if you use PK for all your ssh access you will have to maintain a password just for nx sake. Come on in the year 2010 (or 2011 for that matter) it is totally idiotic to use ssh with passwords for normal daily jobs.
That's why NX made its way out of my door very shortly after trying it out.
If you want to know the whole story then read on.
What really happens with NX is that your client first opens a ssh session to nx@server - this session uses PK auth. Unfortunately the private key is well known, as it ships with a default one and almost noone bothers with replacing it (in fact it is not advised - lol). That means anyone in the world can open that connection to your server and get authenticated and proceed to step 2.
Coming to step 2 after logging to your server as user nx the nx server program is launched. This program actually manages translating the X window protocol to the nx protocol - all the "compression" and stuff. It will set up a DISPLAY variable to point to itself and then launches ANOTHER ssh to you@localhost (localhost being the server). That's where your password comes in.
After that X applications (usually the whole desktop) can be launched under your account, they are going to talk to the sshd spawned by ssh @localhost, where the X protocol is encrypted and compressed, shortly afterwards decompressed and decrypted by the nx server running the ssh command, then translated to nx protocol, encrypted and compressed again through the ssh session for user nx all the way to your client pc where finally decrypted, decompressed, translated to X and displayed on your screen.
As you can see the weird part here is the user nx running the nx server. It is technically absolutely possible to avoid at all this step. The nx server could be easily launched on behalf of the user with the applications spawned from there. IIRC the introduction of the nx account is something as ill as licensing.
Even with the nx account present it is totally irresponsible to leave it protected by well known PK, for the sake of making the installation & deployment 2 clicks easier. The impact is that anyone can launch a nx server on your server. They claim it is secure - hah. At the very least you can start brute forcing passwords for local users, at the other extreme you can find a neat hole to hijack the process and make your way in to the system. Combine with the knowledge of some kernel loophole and you can start scanning for nx enabled systems all over the internet with satisfaction guaranteed.
And even with the ssh@localhost weirdness it is feasible to use PK auth, either by use of ssh agent or some sort of channel forwarding. But no, that's not supported, because...
... enter the customized ssh client shipped with nx which one of the steps involves. Being customized it is never kept up to date so say goodbye to features and say welcome another lot of security holes.
And finally when I read the forums about the open source client wondering if all this mess was fixed at last, I found out that it wasn't/won't - for COMPATIBILITY reasons.
Back then I ran Gentoo so fine tuning your kernel was the norm, and I genuinely believed the terrible performance was due to bad choices I made selecting kernel options. About six months ago I finally abandoned Gentoo and the entire practice of too-tooing with the internals, and switched to Ubuntu, accepting defaults all the way. No I/O improvements noticed. WinXP on the same machine kicks ass.
I first noticed this problem around 2.6.30 where it would terrorize the owners of then-current mainline distros such as the already mentioned Ubuntu. I think there are 2 problems with I/O though:
Lack of general responsiveness with I/O on the background - for example choppy mouse cursor movements, laggy response for keyboard typing - this can be remedied to some extent by using a preemptible kernel and clock at 1000hz and I think it's generally gone after the (proper) low latency hack since 2.6.33 or so.
The other one is crappy work with disk request queues and/or bandwidth, usually when there is one big transfer then all the other stuff has to wait, and there is no way to tell the kernel to do otherwise. A lot of stuff needs disk these days - for example start typing URL in firefox, he has to go to on disk db to fetch completions - thus this one can be particularly annoying. I think this is hardware dependant bug (on some chipsets it bites more) and also there have been some tries to remedy it, namely the I/O stalling patch, which AFAIK has not been yet fully merged and is *maybe* going to go to 2.6.37.
All in all I would call the past year as a pain in the ass of the linux desktop. Especially with distro kernels and their blind shoot in the dark style patches. Custom kernels are highly encouraged.
Every distro can have iptables installed, not all distros do it by default and/or make use of it.
SELinux is not a distro, it is a security module that controls what applications can do, somwhat like normal UNIX security. For example under UNIX you can't open port < 1024 unless you're root, and under SELinux you can't open ports unless explicitly stated in the system-wide policy. Very few distros use SELinux by default however.
You can even combine iptables and SELinux with SECMARK whereas you use iptables firewall to mark packets and SELinux to deny or allow a certain packet to a certain application.
In practicality, the amount of code to perform expansive unit tests quickly dwarfs the amount of code in the product you are testing.
Obviously you write only these that cover some important bugs/functionality. Privilege escalation bug is enough justification.
Like the summary said, the old attack didn't work exactly, it had to be tweaked slightly. Even if you had a unit test for this situation, it most likely would have passed (meaning the test exploit would fail).
That would be true if you wrote a test for the full exploit which is *not* a unit test. A unit test would cover the source of the bug (as opposed to its consequences), that is, ensuring top half of %rax is zero when looking up the syscall table (or just ensuring that %rax is always < nr_syscalls). That sort of test would catch the regression.
Slashdot Mirror
This is one of the downsides of forcing everyone to _register_ just to report a bug. (The other downside is the tremendous pain in the user's butt.) If they only used a simple solution like Request Tracker or so.
This looks awfully similar to my KDE bug tracker experience.
Emphasis mine. The summary almost makes it sound like the researchers just used HIV as we know it ... it's almost humorous to think that a doctor might say "The treatment was a success, you no longer have cancer ... but ..." "BUT WHAT?" "Well, we sorta had to inject you with the HIV in order to take care of it." Obviously this is not the case.
The article also said that they used the virus as a delivery vessel to inject genes of their own choice into the white cells. So not much to do with the real HIV. And ultimately not that "HIV cancels out cancer". Using virii to change genes seems to me as a "normal" thing to do, as it has been noted in press before.
I know what monoculture in security context is. Let me restate my opinion: presenting 10 or so choices of popular distro's is not going to render a significant difference from only 1 choice.
As for botnets or harvesting data: they are doing it. Run a honeypot and you'll get yourself an IRC based botnet in 2-3 days average. Faster than snail mail!
I don't see what you were trying to say about servers. Obviously, the user factor will vanish on a headless machine, but OTOH servers get usually reaped via buggy webapps. The OS role in this is relatively minor.
Your monoculture argument is wrong. From the dawn of times, linux exploits come tailored for the most common distrubutions and some are even intelligent enough to determine the environment at run time. Some can even adjust for non-standard parts replaced by the user. And they have a very good success rate indeed. The number of possible combinations for a typical linux server or workstation is not by a long shot high enough to pose any problem due to environment diversity.
You have a far better point than the other reply to my comment, but nevertheless...
Kernel or other patches are a reactive measure, not proactive such as micro kernel, sandboxing, mandatory access controls, and shifting drivers to userspace (of which linux has the least).
One of the pillars of good security, i.e. ex-post detection of malicious behavior, is completely missing from linux installations, and seemingly from the mentality of the linux community, whereas on windows it is the norm to have an "anti virus" software, which can be pretty efficient in detecting userspace threats and sometimes even stands some chance against kernelspace intrusions.
The point of being able to run a VM legally in linux is valid, but no wide-spread practical application of that is currently available. In fact there's a lot of fine security solutions for linux (unfortunatelly sans the kernel itself) but they all are brutally under-utilized. From that perspective linux desktop is only at the very beginning of the road towards security. I stand with my previous assessment that the lack of linux based malware is from its greater part caused by minimal interest on the part of the criminals.
And yes, when linux becomes so popular that it will attract malware enough, the plan to move to another less known OS is pretty good ;-)
Somehow this has slipped into a linux distro debate. You guys assume that linux is somehow superior in security against botnets, but I don't see why would that be so. Linux browsers, flash, and other apps, are as crappy as on windows, and there is really no obstacle in making a botnet/spyware/... run on linux. In fact it's going to be a lot easier because all distros have things like perl or python. The only thing that protects linux from this is its tiny market share, but see android ... linux based, thus uber secure, right, right?
The problem is the inability of consumers or managers to understand the 3 part rule. Speed, Quality, Cost, pick two.
This rule concerns external quality of the product - as perceived by the customer. The problem with bad code is the *internal* quality - which has impact on the "quotient" for the 3 part rule. The worse the internal quality, the smaller the overall pile from which you "pick two". Eventually with very bad code the development just grinds to a halt.
I think the best analogy for this is furniture. Mennonites make great furniture. It takes a long time, and is very expensive. It is a craft, and they are craftsmen. IKEA makes some pretty shitty furniture but is good enough for many applications. It is cheap, and fast.
Yeah and internal quality (bad code vs good code) would then be the tools with which the furniture is made. Poor shops would assembly every piece by hands of unexperienced workers, great shops just have experienced guys working on top grade machinery. Both poor and great shops can still do the "pick two" tradeoff although it is obvious how their overall productivity would compare. And thats the way it is with shitty code (bunch of cowboy coders working on a yesterday deadline) and great code (tests, refactoring, good planning, experienced people).
Yeah, I've been using Jitsi for some time now, it seems to "just work" for audio/video calls and desktop sharing. It works over xmpp (jabber), which is massive plus, and it supports encryption of transfers in quite easy way. It also crawls over NATs, albeit not as aggressively as skype.
Wrong calculation -- the average pay of the 35% who are willing may not be equal to the average of all tech pros. So the 10% cut might be far from the said figure.
Yep, the one-line answer is:
It's too CPU-intensive for the server.
Cost could be an issue but it's like $100 a year? Hardly a problem for anything but the most amateur of blogs.
It's not that. It's key distribution. Without that HTTPS is simply not secure. I'm surprised that TFA does not mention it. In fact, it talks nonsense. "Everyone knows HTTPS is more secure." Secure from what? Mosquitoes?
But the whole point of this discussion: What if there is a bug in the library that renders that *data*? All of a sudden, your data is no longer very data-y, and much more executable-y than you might have intended.
For reference, take a look at the (lengthy) list of bugs in any of the image processing libraries.
Well, bugs can be fixed. But if you make it a deliberate feature to recklessly run anything that comes into your computer then there's little hope.
It's ok to start playing the movie or load up a slide show of the photos, because all that is just data. What's not ok and where the autorun FAILS is the possibility to execute arbitrary software without user's consent or notice. The same distinction goes with HTML vs Javascript.
How is Apple worse? When did they root kit your iPod or iPhone? Who did they take to court for jail breaking?
Wasn't there some story about Apple bricking all the jailbroken gadgets some time ago?
Exactly! Minimum font size setting in browser makes the site cut off things from the left.
Top of that preferences cannot be saved unless javascript is enabled. Come on guys what is so javascriptish on a SAVE button?
What I said is universally applicable. Graphics does not matter. "A password" can be used on private key too. And "a password" will not help you against someone determined to do the damage if they already have access to your account. Unless this is some sort of protection from 9 year olds that is.
Crashed screen saver usually renders the X session unusable because it would make precautions so that if it crashed then it would not expose working desktop to anyone while you're taking your break. That is at least the old school ones do this, maybe the new fancy ones don't :[
Then the documentation lies...
Yes I devoted some fair time to make it working. (I failed on the PK auth step.) I installed the open/free version from packages so there were no questions asked. Hey maybe I am wrong and all crap like this has already been fixed - good for you/them/whoever then. But back then I assure you it wasn't just any one thing that pissed me off, it was the whole concert of them.
I don't get the point here. You leave your screen unlocked then I gain instant access to where ever you're currently logged on. Plus I can stick a neat backdoor to your user account to automagically hijack all your further sessions (if time allows, depending on the magnitude of bathroom service you're utilizing...)
So please leave your screen locked. (BTW even if you lock it I can stick a key sniffer to your keyboard and pwn you anyway.)
Anyway what you probably originally meant is that PK auth is passwordless. Well it can be used that way but you can also put a password on your private key. Then you have to type that password in order to auth. The key difference here is that neither the password nor the private key leaves your computer and the login is unrepeatable without possession of the private key. That's in contrast to classic password auth where the pw is sent to the server where it can be sniffed and re-used. So what I meant in my original post is that in 2010 there is really no reason to use oldschool insecure auth methods.
Okay my experience with NX is about 18 months old and on behalf of this discussion I re-checked their docs today. It seems there is another way, that is using an internal database of users. The relevant source is http://www.nomachine.com/documents/admin-guide.php section 4. So either you're using that option or you should really re-check your SSH logs and config ;-)
Now I can't find the reference but I swear I saw a paragraph saying something like if you replace the keys then out of box installs will not connect blah blah. Yeah I hear you say "big deal" but ffs this is about serious loss of security so there should never be a default key thus negating the necessity for mentioning "replacing the default key" somewhere in the manual. The keys should be simply generated at install time, with a message popping out "give this [public key content] to any Joe Schmoe you want to access that server of yours".
Sounds weird to me, why the heck would that be so? Both use the same ssh, which supports both.
Ouch. Getting your password transferred to & used at arbitrary locations is hardly more secure than the challenge/response PK schema in which your secrets never leave your computer.
IMO the reasons behind this are merely laziness/incompetence on top of bad design.
I am not. First of all it is un-secure to enter your password somewhere without really having control of where it goes.
Second, it is a pain in the ass. Even if you use PK for all your ssh access you will have to maintain a password just for nx sake. Come on in the year 2010 (or 2011 for that matter) it is totally idiotic to use ssh with passwords for normal daily jobs.
That's why NX made its way out of my door very shortly after trying it out.
If you want to know the whole story then read on.
What really happens with NX is that your client first opens a ssh session to nx@server - this session uses PK auth. Unfortunately the private key is well known, as it ships with a default one and almost noone bothers with replacing it (in fact it is not advised - lol). That means anyone in the world can open that connection to your server and get authenticated and proceed to step 2.
Coming to step 2 after logging to your server as user nx the nx server program is launched. This program actually manages translating the X window protocol to the nx protocol - all the "compression" and stuff. It will set up a DISPLAY variable to point to itself and then launches ANOTHER ssh to you@localhost (localhost being the server). That's where your password comes in.
After that X applications (usually the whole desktop) can be launched under your account, they are going to talk to the sshd spawned by ssh @localhost, where the X protocol is encrypted and compressed, shortly afterwards decompressed and decrypted by the nx server running the ssh command, then translated to nx protocol, encrypted and compressed again through the ssh session for user nx all the way to your client pc where finally decrypted, decompressed, translated to X and displayed on your screen.
As you can see the weird part here is the user nx running the nx server. It is technically absolutely possible to avoid at all this step. The nx server could be easily launched on behalf of the user with the applications spawned from there. IIRC the introduction of the nx account is something as ill as licensing.
Even with the nx account present it is totally irresponsible to leave it protected by well known PK, for the sake of making the installation & deployment 2 clicks easier. The impact is that anyone can launch a nx server on your server. They claim it is secure - hah. At the very least you can start brute forcing passwords for local users, at the other extreme you can find a neat hole to hijack the process and make your way in to the system. Combine with the knowledge of some kernel loophole and you can start scanning for nx enabled systems all over the internet with satisfaction guaranteed.
And even with the ssh@localhost weirdness it is feasible to use PK auth, either by use of ssh agent or some sort of channel forwarding. But no, that's not supported, because...
... enter the customized ssh client shipped with nx which one of the steps involves. Being customized it is never kept up to date so say goodbye to features and say welcome another lot of security holes.
And finally when I read the forums about the open source client wondering if all this mess was fixed at last, I found out that it wasn't/won't - for COMPATIBILITY reasons.
Sad story.
Then I removed the RAM to bring it down to 256k, and it still ran decently (for single tasking).
That shouldn't work. Rumor there is that win7 requires at least 640k.
Back then I ran Gentoo so fine tuning your kernel was the norm, and I genuinely believed the terrible performance was due to bad choices I made selecting kernel options. About six months ago I finally abandoned Gentoo and the entire practice of too-tooing with the internals, and switched to Ubuntu, accepting defaults all the way. No I/O improvements noticed. WinXP on the same machine kicks ass.
I first noticed this problem around 2.6.30 where it would terrorize the owners of then-current mainline distros such as the already mentioned Ubuntu. I think there are 2 problems with I/O though:
Lack of general responsiveness with I/O on the background - for example choppy mouse cursor movements, laggy response for keyboard typing - this can be remedied to some extent by using a preemptible kernel and clock at 1000hz and I think it's generally gone after the (proper) low latency hack since 2.6.33 or so.
The other one is crappy work with disk request queues and/or bandwidth, usually when there is one big transfer then all the other stuff has to wait, and there is no way to tell the kernel to do otherwise. A lot of stuff needs disk these days - for example start typing URL in firefox, he has to go to on disk db to fetch completions - thus this one can be particularly annoying. I think this is hardware dependant bug (on some chipsets it bites more) and also there have been some tries to remedy it, namely the I/O stalling patch, which AFAIK has not been yet fully merged and is *maybe* going to go to 2.6.37.
All in all I would call the past year as a pain in the ass of the linux desktop. Especially with distro kernels and their blind shoot in the dark style patches. Custom kernels are highly encouraged.
a lot of people don't use it just for Farmville
Now this is news. What, did they put up another game?
Every distro can have iptables installed, not all distros do it by default and/or make use of it.
SELinux is not a distro, it is a security module that controls what applications can do, somwhat like normal UNIX security. For example under UNIX you can't open port < 1024 unless you're root, and under SELinux you can't open ports unless explicitly stated in the system-wide policy. Very few distros use SELinux by default however.
You can even combine iptables and SELinux with SECMARK whereas you use iptables firewall to mark packets and SELinux to deny or allow a certain packet to a certain application.
Just to clarify I understand that there are two zero day root-providing bugs. (Everyone talks about THE bug.)
CVE-2010-3301 patched by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=36d001c70d8a0144ac1d038f6876c484849a74de and http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=eefdca043e8391dcd719711716492063030b55ac
CVE-2010-3081 patched by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c41d68a513c71e35a14f66d71782d27a79a81ea6
In practicality, the amount of code to perform expansive unit tests quickly dwarfs the amount of code in the product you are testing.
Obviously you write only these that cover some important bugs/functionality. Privilege escalation bug is enough justification.
Like the summary said, the old attack didn't work exactly, it had to be tweaked slightly. Even if you had a unit test for this situation, it most likely would have passed (meaning the test exploit would fail).
That would be true if you wrote a test for the full exploit which is *not* a unit test. A unit test would cover the source of the bug (as opposed to its consequences), that is, ensuring top half of %rax is zero when looking up the syscall table (or just ensuring that %rax is always < nr_syscalls). That sort of test would catch the regression.