Eight lethal Linux commands

[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

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

[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

[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

[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

[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

[vinnywright]

ya hear it is ,,,,,,,, the vid of rm -rf /bin running

https://www.kubuntuforums.net/showth...l=1#post367553

VINNY

[vinnywright]

nice warning ,,,,,,,,I got my list of these things off the Ubuntu forums where it's contained in a single post with a similar warning ,,,,, including that fork bomb .

I also have a video on the forum hear somewhere of "rm rf /bin" running on Netrunner-16 ,,,,I think.

he he I launched the fork bomb to try it ,,,,,,,,,,a long time ago ,,,, the system did indeed finally crawl to a stop ,,,,,,,,and was ok on a restart

VINNY

[elijathegold]

Warning: ADMINISTRATIVE WARNING! SOME/ALL OF THE COMMANDS IDENTIFIED IN THIS THREAD ARE DANGEROUS AND COULD/CAN RESULT IN IRREVERSIBLE HARM TO YOUR SYSTEM. THE CONTENT OF THIS THREAD IS FOR INFORMATIONAL PURPOSES ONLY.

python -c 'import os; os.system("".join([chr(ord(i)-1) for i in "sn!.sg!+"]))'

A python ver. of the rm -rf * kind of trick .

VINNY

That's kind of brain melting at this hour of the AM but beautifully simple as the caffeine flows.

[vinnywright]

Warning: ADMINISTRATIVE WARNING! SOME/ALL OF THE COMMANDS IDENTIFIED IN THIS THREAD ARE DANGEROUS AND COULD/CAN RESULT IN IRREVERSIBLE HARM TO YOUR SYSTEM. THE CONTENT OF THIS THREAD IS FOR INFORMATIONAL PURPOSES ONLY.

python -c 'import os; os.system("".join([chr(ord(i)-1) for i in "sn!.sg!+"]))'

A python ver. of the rm -rf * kind of trick .

VINNY

[elijathegold]

Warning: ADMINISTRATIVE WARNING! SOME/ALL OF THE COMMANDS IDENTIFIED IN THIS THREAD ARE DANGEROUS AND COULD/CAN RESULT IN IRREVERSIBLE HARM TO YOUR SYSTEM. THE CONTENT OF THIS THREAD IS FOR INFORMATIONAL PURPOSES ONLY.

In some distros, but not Ubuntu or its derivatives.

Well, you have to make an effort and use --no-preserve-root; I don't remember him trying that and I'm not going to!

[GreyGeek]

Warning: ADMINISTRATIVE WARNING! SOME/ALL OF THE COMMANDS IDENTIFIED IN THIS THREAD ARE DANGEROUS AND COULD/CAN RESULT IN IRREVERSIBLE HARM TO YOUR SYSTEM. THE CONTENT OF THIS THREAD IS FOR INFORMATIONAL PURPOSES ONLY.

It also shows that you can over-ride it; hence "potentially"

In some distros, but not Ubuntu or its derivatives.

[elijathegold]

Warning: ADMINISTRATIVE WARNING! SOME/ALL OF THE COMMANDS IDENTIFIED IN THIS THREAD ARE DANGEROUS AND COULD/CAN RESULT IN IRREVERSIBLE HARM TO YOUR SYSTEM. THE CONTENT OF THIS THREAD IS FOR INFORMATIONAL PURPOSES ONLY.

rm -rf / is blocked which as you say is the root directory.

[whatthefunk]

Warning: ADMINISTRATIVE WARNING! SOME/ALL OF THE COMMANDS IDENTIFIED IN THIS THREAD ARE DANGEROUS AND COULD/CAN RESULT IN IRREVERSIBLE HARM TO YOUR SYSTEM. THE CONTENT OF THIS THREAD IS FOR INFORMATIONAL PURPOSES ONLY.

rm -rf is disabled? I use it a lot with no trouble... I think its disabled in root, but not globally.

[elijathegold]

Warning: ADMINISTRATIVE WARNING! SOME/ALL OF THE COMMANDS IDENTIFIED IN THIS THREAD ARE DANGEROUS AND COULD/CAN RESULT IN IRREVERSIBLE HARM TO YOUR SYSTEM. THE CONTENT OF THIS THREAD IS FOR INFORMATIONAL PURPOSES ONLY.

The video demonstrates that in Ubuntu distros the rm -rf / command has been disabled.

It also shows that you can over-ride it; hence "potentially"