Eight lethal Linux commands

[jlittle]

For the hell of it, and after Friday beers, I started a fork bomb on a client's development machine running HP-UX, some years ago now. It was a big box (literally, as well as the lots of resources sense) that could be used for production if needed. It didn't miss a beat; the user process limit, 1000 I think, was reached quickly, then HP-UX was as normal. I logged on as another user, suspended all the fork bombs using kill, then killed them all.
Can Linux be configured to have similar robustness?

Regards, John Little

[elijathegold]

You can set the maximum number of processes that a user has access to. (link). On Kubuntu 14.04 running ulimit -u shows that I can start 127,505 processes. I don't know if this is a dangerously high number, but I would definitely want to reign it in on a public facing server.

You can protect against the rm -rf / style of attack by placing a script called rm higher in the path. This script would sanity check what the user is doing and either throw a tantrum or get confirmation and then pass it on to the real rm command. Or you could alias rm to rm -i so that it asks before removing each file. Neither of these are a perfect solution as they can be bypassed.

I would suppose that a victim of a rm -rf / who was running btrfs, could simply boot an appropriate live environment and restore a snapshot?

--- EDIT ---

I seem to have become a bit curious regarding this subject and while digging around found that two commands should stop the bash fork bomb. Assuming I started it running then use:

killall -STOP -u elijathegold
killall -KILL -u elijathegold

Now all we need is a volunteer with an enquiring mind, a virtual PC and a few moments to spare

[GreyGeek]

....

I would suppose that a victim of a rm -rf / who was running btrfs, could simply boot an appropriate live environment and restore a snapshot?

Yes, assuming snapshots were taken before the fork bomb exploded.
Here is a listing of the two snapshots I made on May 4th.

[FONT=monospace][COLOR=#000000]~# mount /dev/sda1 /mnt [/COLOR]
~# vdir /mnt 
total 0 
drwxr-xr-x 1 root root 246 May  6 17:22 @ 
drwxr-xr-x 1 root root  50 Apr 19 16:20 @home 
drwxr-xr-x 1 root root  50 Apr 19 16:20[B] @home_snapshot_20160504[/B] 
drwxr-xr-x 1 root root 246 Apr 19 16:38 [B]@_snapshot_20160504[/B]
[/FONT]

At the grub go to the repair option, choose the root terminal, remount the drive as rw. Mkdir /mnt if it does not exist.
Mount the live filesystem as shown above. @ and @home may be empty but the snapshots won't be because they are not accessible from the CLI.
mv /mnt/@ /mnt/@_bad
mv /mnt/@home /mnt/@home_bad
mv /mnt/@_snapshot_20160504 /mnt/@
mv /mnt/@home_snapshot_20160504 /mnt/@home
reboot
If things are working properly remount the live filesystem on /mnt, delete @_bad and @home_bad snapshots and make new ones:
btrfs subvolume delete /mnt/@_old
btrfs subvolume delete /mnt/@home_old

btrfs subvolume snapshot /mnt/@ /mnt/@_20160512
btrfs subvolume snapshot /mnt/@home /mnt/@home_20160513

[jlittle]

Mmm, sounds like fun... A thing about fork bombs is that when a limit is reached, they run continuously getting errors and burning CPU, so the OS needs to limit CPU time, and presumably memory as well. So, write the script to handle the error by terminating, say 50% of the time. This would make the process ids churn about, making race conditions with attempts to suspend them...
Note to self: google hardening Linux.

Regards, John Little

[quaksoul1]

I feel rm -I option is not worth anything. rm -i is worth even less. rm -I should only work on directories, not every piece of file more than 3 files.

[woodsmoke]

Nickstone wrote:

s u d o apt-get install kubuntu-desktop

will explode your pc or some such.

I HAVE heard that installing a "desktop" will do that...

However, again, I repeat myself.....if there is nothing tweaked on your install, lets say you have a "plain-vanilla" Debian or Ubu....and pretty plain vanilla metal...it can be done, and is done..

I've installed "the Kubuntu desktop" and "the KDE desktop' on top of plain vanialla Debian and Ubu and things worked fine.

I've also installed ..ALMOST lol all of the following on Debian and / or Ubu...


http://www.junauza.com/2008/08/20-mo...-x-window.html

But, the highly important thing is doing it on a clean install, with absolutely no tweakage and on "plain vanilla" metal so that the DE would be "aware" of both the base OS and the hardware...

I'm not criticizing the comment, just providing another perspective.

woodactuallylikedAfterstepalotbackinthedaysmoke