To view parent comment, click here.
To read all comments associated with this story, please click here.
That just takes care of one tool which can bring the system to its knees, limiting access to dd is a bandage. The issue is that any application on Linux can cause the system a great deal of stress or bring it down. (I do this a couple of times a year by accident.)
There are ways to protect against this kind of attack (accidental or not) such as setting resource limits on user accounts. Most distributions do not appear to ship with these in place by default, but if your system requires lots of uninterrupted uptime, the sysadmin should consider locking down resource usage.
There are ways to protect against this kind of attack (accidental or not) such as setting resource limits on user accounts. Most distributions do not appear to ship with these in place by default, but if your system requires lots of uninterrupted uptime, the sysadmin should consider locking down resource usage.
It the same case for all OSs though. Trying to open a 200MB Excel spreadsheet that some office idiot decided to build a database in will easily bring Windows to it's knees.
The moment you put an idiot in front a computer than that machine is as good as dead. Regardless of the OS. There's a saying that goes something like "The more you dumb something down, the bigger idiot that come along".
Laurence,
"If Linux gets exhausted of RAM, then the requesting application is killed and an OOE (out of memory exception) raised in the event logs."
Isn't the default behaviour under linux to call the out of memory killer? It takes over and heuristically decides which process to kill. I'm opposed to the OOM killer on the grounds that it randomly kills well behaved processes, even when they handle out of memory conditions in a well defined way.
Playing devil's advocate, OOM killer gives the user a chance to specify weight factors for each process to give the kernel a hint about which processes to kill first (/proc/1000/oom_adj /proc/1000/oom_score etc). This increases the likelihood that the kernel will kill a process that is responsible for consuming the most ram. Without the OOM killer, a small process (ie ssh) can be forced to terminate when another process (dd bs=4G) is responsible for hoarding all the memory. Killing the large "guilty" process is better than killing small processes that happen to need more memory.
I am interested in what others think about the linux OOM killer.
"mv `which dd` /sbin/ problem solved."
I don't think that addresses the root concern, which is that userspace processes can abuse system resources to the point of grinding the system to a halt. dd was a simple example, but there are infinitely more ways to do similar things. If our goal was to deny access to all the commands with potential to overload system resources, we'd be left with a virtually empty set. Obviously you'd have to deny access to php, perl, gcc, even shell scripts. The following does an excellent job of consuming both CPU and RAM on my system until I run out of memory and it aborts:
cat /dev/zero | gzip -c | gzip -d | gzip -c | gzip -d | gzip -c | gzip -d | sort > /dev/null
It's not likely to happen accidentally, but if a user is determined to abuse resources, he'll find a way!
Isn't the default behaviour under linux to call the out of memory killer? It takes over and heuristically decides which process to kill.
Well yeah, that's what i just said.
I'm opposed to the OOM killer on the grounds that it randomly kills well behaved processes, even when they handle out of memory conditions in a well defined way.
Yeah, i've often wondered if there was a better way of handling such exceptions. OOM doesn't sit nicely with me either.
Playing devil's advocate, OOM killer gives the user a chance to specify weight factors for each process to give the kernel a hint about which processes to kill first (/proc/1000/oom_adj /proc/1000/oom_score etc). This increases the likelihood that the kernel will kill a process that is responsible for consuming the most ram. Without the OOM killer, a small process (ie ssh) can be forced to terminate when another process (dd bs=4G) is responsible for hoarding all the memory. Killing the large "guilty" process is better than killing small processes that happen to need more memory.
Interesting concept. A little tricky to impliment I think, but it has potential.
I don't think that addresses the root concern, which is that userspace processes can abuse system resources to the point of grinding the system to a halt. dd was a simple example, but there are infinitely more ways to do similar things. If our goal was to deny access to all the commands with potential to overload system resources, we'd be left with a virtually empty set. Obviously you'd have to deny access to php, perl, gcc, even shell scripts. The following does an excellent job of consuming both CPU and RAM on my system until I run out of memory and it aborts:
cat /dev/zero | gzip -c | gzip -d | gzip -c | gzip -d | gzip -c | gzip -d | sort > /dev/null
It's not likely to happen accidentally, but if a user is determined to abuse resources, he'll find a way!
But that's true for any OS. If a user has access to a machine then it would only take a determined halfwit to bring it to it's knees.
The only 'safe' option would be to set everyone up with thin clients which only have a web browser installed and bookmarked link to cloud services like Google Docs.





Member since:
2007-03-26
mv `which dd` /sbin/
problem solved.
Edited 2012-10-27 20:18 UTC