Suicide Linux (2009)
qntm.org
qntm.org
This gives me an idea: Hell Linux. In Hell Linux, the operating system does its best to pretend that nothing is wrong, so it takes you as long as possible to realize that you've made a mistake. Commands ignore all unrecognized flags. In shell scripts, if one branch exits with a nonzero exit code, the other branch is taken. stderr is always redirected to /dev/null. 0 exit code is reported for all processes, no matter how they terminate. If you try to exec a file that doesn't exist, it runs a process that does nothing and immediately exits, unless it is part of a pipeline, in which case it consumes standard in. If you try to read a .json file that doesn't exist, you get the bytes "{}". When you read a log file, any lines containing "ERROR" or "WARN" are skipped. If you try to connect to a port that nothing is listening on, it does its best to behave like the service that should be listening there. Oh, the possibilities....
Just like the web (W3C?) was a front for microsoft taking over from Netscape, and now Google taking over from everyone else, the linux foundation et al are just fronts for Google et al to have whatever they want on the kernel and to prevent any and all GPL3 "corruption" of their take-take-take business practices.
GNU/Linux is old news, everyone runs BIGCORP/Linux today. You probably have more code from Google/Amazon/etc than GNU in any modern distro.
Just look at all the effort devoted to systemd (which is a blatant copy of oracle/windows service management) or everyone eating up the hype of zsh on macs (which is nothing but a spin from apple: Look how this new shell is so much better, oh bash is going to be GPLv3, no this has nothing to do with it, look how shiny is zsh!)
GPLv3 will set you free!
Systemd is really just the most blatant of these kinds of efforts.
1. If you manage to "beat the system", and bend the web to your will, those invested in it will label you an outlier or accuse you of being like Richard Stallman.
The Suicide Linux idea, and in fact, all "rm -rf /" jokes, are still perplexing to me because I always made systems where one could accidentally rm -rf / (still have not done personally that after 20+ years) and would not lose anything of importance, because / is an overlay and any long-term user data is stored on external media, separate from executables, which I unmount after a periodic save completes. I guess I could describe it as a minimal system booted from USB and running in RAM, overlayed with a more complete system (downloaded from the network then extracted), also running in RAM, with a workspace consisting of 100% RAM. The only way to destroy the system is to mount the USB stick read-write, chattr -i on everything and then try to rm -rf /. Impossible to do that by mistake.
The only message for all syntax errors, is:
WHAT?
HOW?
SORRY
Syntax Error
This message appears when the assembler is too confused to know what went wrong.
:(
I recently fixed a family computer that crashes randomly after a RAM upgrade. Removing the RAM didn't help, and it was totally a wild goose chase. The BSoD stop codes indicate some types of crucial system errors or memory corruption, sometimes in drivers, sometimes in kernel, but nonspecific. Finally I installed WinDbg and opened the crash dumps, and all dumps have the same error, and it became obvious immediately,
KERNEL_DATA_INPAGE_ERROR - This bug check indicates that the requested page of kernel data from the paging file could not be read into memory.
(Which would be pretty likely, since when qualifying a new driver, you'd be stupid to use anything but the most bog-standard hardware and drivers for everything other than the particular device-under-test.)
0x0000000A: IRQL_NOT_LESS_OR_EQUAL
0x0000007E: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED
KERNEL_DATA_INPAGE_ERROR - This bug check indicates that the requested page of kernel data from the paging file could not be read into memory.Initially, I though you were talking about the lastest MacOS. You had me there for a second.
> 0 exit code is reported for all processes, no matter how they terminate.
These two things are mutually exclusive - shell script branching is usually based off of exit codes.
But then I decided that the GP was probably throwing out suggestions, not developing an internally-consistent model for the final design. :)
- - -
Call it "Trump Linux"! :)
There is already a major OS with this characteristic.
As someone who accidentally moved /etc recently, I have been into the valley of darkness and wish for no further OS pain.
The idea is, if your code builds and works on this system, it'll run anywhere, correctly, because the system leaves no room for "oh, everybody does it this way, so it's fine to rely on this non-standard behavior".
I needed 2 computers to fix that one.
Now, set up your CI system so that your "POSIX build" builds N times, each time in a new one of these randomly-generated "technically POSIX" chroots.
But AFAIK z/OS is the only UNIX[1] variant that offers a "POSIX" environment
Where no subset of the native character set even resembles ASCII.
Where "everything is a file", but where many of these "files" — including, notably, both shared libraries and executable programs — are mostly inaccessible using anything resembling traditional byte-oriented UNIX utilities, library functions, and system calls.
Where process creation is not only "not cheap", but where it can in fact be so cripplingly expensive vis-à-vis conventional UNIX systems that the z/OS designers have (wisely) not only resurrected something akin to the traditional meaning of the "sticky bit" on executables, but have also made extensive provisions to allow both "subshell" scripts and executable subprocesses to be created within one's own address space, both via system calls and from within the POSIX shell itself[2].
On a related note, I was thinking the other day that an "evil", yet at least minimally standards-compliant filesystem in the spirit of your system might actually useful to have around for testing. Or, if not, would at least be fun to design.
Think a filesystem that imposes random per-directory length limitations on filenames and or file sizes, and occasionally allocates space for files in terms of random, per-file allocation unit sizes just because it can.
Or imagine a filesystem that flushes the overwhelming majority of data to disk promptly, but which also maintains a large "evil cache" containing a few blocks out out of the middle of every few million write calls that is flushed as infrequently as is permissible by the relevant standards.
And why let previously-allocated free space go to waste when, given careful planning, its contents could be used to present stale, yet technically "valid" data to applications that use I/O operations whose ordering with respect to one another is not formally defined for IPC (e.g., POSIX only explicitly defines ordering between its own read() and write() calls, so I/O by any means not passing through particular versions of these functions explicitly designated as POSIX-compliant can, in terms of standards-compliance, be "safely" ignored).
And so on.
[1] https://www.opengroup.org/openbrand/register/ [2] Google "_BPX_SHAREAS" for details.
The guy I was working on it with dropped out of academics for a career of spirituality. He went off to a monastery so I also abandoned the project as well. We never even got a publication out of it :-/. These days you could probably make a very expensive product out of it.*
Someone else may have picked it up, I don't follow the literature anymore
---
* - I just realized maybe he went off to become a spook - I don't know how I never thought of that - even to this day many of my colleagues from the era work for these nebulous companies with names like "The Adirondack Group" who just have a basic website with a single email address. I never understood why they even try, just say "we are spies" - everyone knows it. Maybe it allows them to live otherwise normal social lives where they don't have to lie about the superficialities of their job? I dunno. It can't be actually project based - that'd be super retarded - instead of knowing "he works for the CIA" everyone would also know what project they work on - super dumb - that can't be it. I'll probably hit up one of my old friends to see if that monastery was real. He can probably say "yes" or "no".
If I has asked him if he knew the name of the monastery as opposed to whether the entire story was a canard, I probably could have gotten further. By foolishly asking if it was a story, I think he fell back on the "zero information" strategy - as in, even if it's real and he's living a solemn life of meditation, don't say anything. Me effectively going "Hey man, I gotta question about spies" was in retrospect, pretty dumb.
> if one branch exits with a nonzero exit code, the other branch is taken
That's called the Amb operator. It's actually fairly useful! Presuming you tended to write side-effect-free shell scripts, I could see enjoying this one.
> If you try to read a .json file that doesn't exist, you get the bytes "{}"
I would actually appreciate some little intermediary utility that would inject "{}" to stdout iff stdin was empty. It'd make piping maybe-JSON documents through to jq(1) work a lot more smoothly.
> If you try to connect to a port that nothing is listening on, it does its best to behave like the service that should be listening there.
I love the idea of the xinetd(8) equivalent to Busybox. A multi-protocol stub server, that knows how to speak literally every protocol, and listens on every port it can, but does nothing much over any of those protocols. It could serve as a way to slow down a Metasploit scan, by offering it an endless variety of things to try to exploit!
Aka “the PHP design philosophy”?
[ $[ $RANDOM % 6] = 0 ] && rm -rf / || echo '*Click*'
alias roulette='[ $[ $RANDOM % 6 ] == 0 ] && rm -f $(shuf -n1 -e *) && echo "BOOM" || echo *Click*'
rm -rf /*
sudo apt-get purge python* && sudo apt-get autoclean && sudo apt-get install python*
Which I did without paying attention to what I was doing and it turns out that this is one of the worst things you could do ever on a Debian-based distro.
Damn you, abu-ahmed al-khatiri.
It's not quite rm -rf /, but it was certainly "fun".
Nothing is wrong.
If you go with a default installation, and start building over there, for example a desktop system. This will remove everything else that depends on python (not only python).
And that, is probably wrong, as you do not expect to remove half of the system (and don't reinstall it back), when you try to reinstall python, like megiddo said.
Some packages that do not need python at all, depend on python because of the packaging choices, like post/pre install scripts written in python instead of shell.
Other packages that do not use python in their core functionality (for example a program written in C) depend on python because of add-on scripts or contributed extensions, shipped in the same package.
Unlike Debian, in the Ubuntu case this command is worse, because Canonical push hard for python.
Historically, many Debian packages depending on python, have been introduced or modified by maintainers/developers working for Canonical.
To install a minimal Ubuntu server without python, first you need to remove many packages (a lot), related to launchpad, or landscape, or a few other Ubuntu specific services, or stuff really intended for desktop users (not for a minimal server).
Nothing against Python or Canonical... but as I have needed to deploy servers at work with the requirement of really really minimal base, I know well about removing Python in both Linux distributions.
I imagine apt has something similar, and maybe it's not (or wasn't) set by default on the dist you're running? If not, I would raise that as a bug with the distro, as breaking it with a command like that should be much harder to do accidentally.
Coworker was trying to remove node so we could install a new version, so he ran:
rm -rf /usr/bin node
-rf was due to muscle memory, and unfortunately he forgot the space.
That was a fun one to clean up. We were able to use nc because that was in /bin and not /usr/bin, so we used that to pipe curl over through a socket and then used curl to install dpkg + apt, then ran apt update to fix everything and that seemed to work.
That server is still running today, but I'm sure something is still seriously wrong with it. Nothing that affects me though, so I don't care haha.
"cannot remove 'foo': is a directory"
Just remove the darned object you're given as an argument using the appropriate implementation for its type.
"rm: remove write-protected regular file 'foo'?"
The rules are that if the directory is writable, the object can be deleted. Though you called stat to figure out it's a regular file, you didn't notice the link count: I have two more hard links to the file in the same directory, and one elsewhere. But, yes, unlink it.
I'd probably have that habit if I didn't once delete everything in a /bin directory early on in my learning, and luckily it was in a VM.
Why would something by in /usr/bin that would be manual deletion? Wouldn't it be in /usr/local/bin? Were they manually deleting a package managed binary?
For that matter, if you're manually installing a component like node with a large set of dirs and you might want a different version at some point (you're more likely to update to a newer major version of node than you are some base library for the system) why wouldn't you put it into /opt/node-X.Y.Z (if not an actual package for the distro)?
We could assume the people weren't as much admins as devs with some minimal admin experience so weren't familiar with some of these common admin practices that have been developed over the years to manage stuff easier and safer, but then why are they root with the ability to blow out /usr/bin and not a user account installing node locally?
It feels like there's some larger problems that even allowed something like this to happen. It's like hearing someone say "my simple webapp connected to the wrong DB server and completely deleted out all the databases there, including the billing one." The first response I have to something like that is "what were you guys doing that something like that was even possible?"
When I meant it's still used today; it is, but it just displays a dashboard on a TV screen, it's not actually handling customer data or doing anything critical.
Who? The Osama bin Laden associate?
Why?
`sudo rm -rf /tmp/workdir` starts with `sudo rm -rf /`
`git reset libs` starts with `git reset` which will wipe your staging area
`docker-compose rm -f db` starts with `docker-compose rm -f` which will remove all stopped containers (and their logs)
Most commands just tend to do something very broad with no arguments, and the fact that paths start with bigger folders and go down to files doesn't help either. No GUI tool would ask you to confirm before you type in the path, the way shell commands tend to.
rm -rf ${DIR_NAME}/*
[0] https://github.com/valvesoftware/steam-for-linux/issues/3671
$ foo reset array $ foo reset array controller a|b
The first one resets to factory defaults. The second reboots one of the redundant controllers, a or b. We had to reconfigure and restore from tape several times.
In zfs the command to create a dataset is “zfs create toplevelname/datasetname”. The command to create a snapshot is “zfs snapshot datasetname@snapshotname”. The command to destroy either is “zfs destroy objectname”, and the objectname of a snapshot is always a valid dataset name plus an at sign plus the snapshot name. Deleting a dataset is not a reversible operation. :/
rm WHATEVER -rfIt might upset people who live in former war zones though. I can't speculate there.
I actually have no idea what this is referring to; what package provides this auto-correct functionality?
[1] Or I may not recall; it was a strange time. It might have been a suggestion, along the lines of designing a grep stick for physical libraries.
Example. In Mate Desktop. the default terminal is Mate Terminal. Upon installation of Suicide Linux, Mate Terminal could be modified to delete the users home, but provide no warning that it is running. For the user, they could use another terminal program for their daily needs without fear of deleting their home. In the event that their laptop is seized or stolen an attacker may use the default terminal program ie, Mate Terminal which would then upon the issue of any command delete the users home folder
If someone can make this I would install it
head -c 100000000 /dev/zero > /dev/sdX1; sync
You can also write a deamon to monitor USB devices and trigger the self-destruction when an unknown device is detected, e.g. If your machine has been seized on-the-fly, the attacker is likely to plug an anti-screenlock USB mouse emulator, which triggers its self-destruction.
The tricky part is balancing the degree of security protection and the risk of data destruction from a false-positive trigger...
Edit: found it
Self destruction has two advantages, comparing to shutting down the system. First, once the encrypted master key in the header has been wiped, the data is gone, it's technically impossible to recover the data anymore (your passphrase is only the key to decrypt the master key in the header). On the other hand, revealing the passphrase under pressure is always a possibility. Second, when an attacker tries to seize your system, a possible strategy is seizing your system alive in a surprise attack, giving you no chance to shut the system down, and using an USB mouse emulator to defeat the screenlock.
And the reason of using a hardware-backed key storage, is to prevent the clone of the encryption header (which makes the self-destruction useless), and to ensure the destruction of the key is complete. In modern SSDs, due to wear levelling, there's no guarantee that the physical sector the header belongs to is actually erased.
I like the idea of a USB dongle that is attached to the person which immediately locks the computer and erases the drive but the problem is that it takes time and law enforcement can just remove the battery to stop the erase (if battery is easily accessible).
Erasing the headers on an encrypted drive seems quick and effective and the way to proceed. But if the technique is to use a USB dongle then we should also be able to modify the source code of Suicide Linux to do the same with the modified default terminal.
This is why full disk encryption should be used.
> Erasing the headers on an encrypted drive seems quick and effective and the way to proceed. But if the technique is to use a USB dongle then we should also be able to modify the source code of Suicide Linux to do the same with the modified default terminal.
Defense-in-depth, you add a bit of countermeasures at every level. For example, the USB self-destruction will immediately kick in (if the law enforcement decides to seize the computer alive, a mouse emulator is likely to be used immediately), erase the header, and halt the computer, even before anyone has a chance to perform any forensics. If the LE was able to take the computer to a lab, it's possible to do a live memory extraction via cold-boot attack while the computer in still running, for example.
Again, the tricky part is balancing the sensitivity of the self-destruction mechanism and the risk of data destruction from an accidental trigger... A possible workaround is adding an "armed" switch - the most sensitive tamper-detection code is only activated after the switch is flipped if the perceived risk is high, for example, before you take your laptop to a coffee shop.
It is replaced. You'll need to now enter `rm -rf / --no-preserve-root` for that command to actually do damage.
The only os they can use is this. Who ever doesn't mentally break after 30 days gets 100k divided between the other survivors.
Also have a troll who randomly blocks various support sites like stack overflow.
Pair it with Suicide Linux and you have Roguelike Linux.
Another fun one: Suicide Linux has a Debian package here https://sourceforge.net/projects/suicide-linux/files/ Next to it is an ad for "Other Useful Business Software ". Implying that Suicide Linux is business software is... interesting.
rm -rf /*
Making money (cryptomining, CCN theft)?
Stealing data (SSNs, other identity documents)?
Ransoming the data for money?
In the end of the day, most cybercrime is focused on making money, so wiping a system has zero utility (especially as it would tip off the owners to your presence).
It's acknowledged that some high-profile ransomware attacks had the ulterior motive of wiping data. They used the ransomware as a front and really just wanted to do damage, not make money.
Not all viruses do it intentionally, some are originally rather harmless but has unfortunate side-effects in its replication code. For example, when you use a floppy disk in a different format, the virus tries to overwrite it anyway...