Linux

What's stopping the downloaded script from wiping my home directory?

What's stopping any Makefile, build script, or executable from running rm -rf ~? The correct answer is "nothing". PPAs are similarly open, things are a little safer if you only use your distro's default package sources, but it's always possible that a program will want to be able to delete something in your home directory, so it always has permission.

Containerized apps are the only way around this, where they get their own home directory.

For security reasons, I review every line of code before it’s executed on my machine.

Before I die, I hope to take my ‘93 dell optiplex out of its box and finally see what this whole internet thing is about.

It isn’t more dangerous than running a binary downloaded from them by any other means. It isn’t more dangerous than downloaded installer programs common with Windows.

TBH macOS has had the more secure idea of by default using sandboxes applications downloaded directly without any sort of installer. Linux is starting to head in that direction now with things like Flatpak.

You have the option of piping it into a file instead, inspecting that file for yourself and then running it, or running it in some sandboxed environment. Ultimately though, if you are downloading software over the internet you have to place a certain amount of trust in the person your downloading the software from. Even if you're absolutely sure that the download script doesn't wipe your home directory, you're going to have to run the program at some point and it could just as easily wipe your home directory at that point instead.

What's stopping the downloaded script from wiping my home directory?

Lol. Lmao

If you're worried, download it into a file first and read it.

You could just read the script file first.. Or YOLO trust it like you trust any file downloaded from a relatively safe source.. At least you can read a script.

The security concerns are often overblown. The bigger problem for me is I don't know what kind of mess it's going to make or whether I can undo it. If it's a .deb or even a tarball to extract in /usr/local then I know how to uninstall.

I will still use them sometimes but for things I know and understand - e.g. rustup will put things in ~/.rustup and update the PATH in my shell profile and because I know that's what it does I'm happy to use the automation on a new system.

I usually read it first.

I think safer approach is to:

1. Download the script first, review its contents, and then execute.
2. Ensure the URL uses HTTPS to reduce the risk of man-in-the-middle attacks

This is just normal Linux poor security. Even giants like docker do this.

This is simpler than the download, ./configure, make, make install steps we had some decades ago, but not all that different in that you wind up with arbitrary, unmanaged stuff.

Preferably use the distro native packages, or else their build system if it's easily available (e.g. AUR in Arch)

| sh stands for shake head at bad practices

You shouldn't install software from someone you don't trust anyway because even if the installation process is save, the software itself can do whatever it has permission to.

"So if you trust their software, why not their install script?" you might ask. Well, it is detectable on server side, if you download the script or pipe it into a shell. So even if the vendor it trustworthy, there could be a malicious middle man, that gives you the original and harmless script, when you download it, and serves you a malicious one when you pipe it into your shell.

And I think this is not obvious and very scary.

https://sysdig.com/blog/friends-dont-let-friends-curl-bash/
https://www.seancassidy.me/dont-pipe-to-your-shell.html
https://web.archive.org/web/20200131173255/https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/
https://github.com/Iossefy/curl-shell-pipe

It's not much different from downloading and compiling source code, in terms of risk. A typo in the code could easily wipe home or something like that.

Obviously the package manager repo for your distro is the best option because there's another layer of checking (in theory), but very often things aren't in the repos.

The solution really is just backups and snapshots, there are a million ways to lose files or corrupt them.

Unpopular opinion, these are handy for quickly installing in a new vm or container (usually throwaway) where one don't have to think much unless the script breaks. People don't install thing on host or production multiple times, so anything installed there is usually vetted and most of the times from trusted sources like distro repos.

For normal threat model, it is not much different from downloading compiled binary from somewhere other than well trusted repos. Windows software ecosystem is famously infamous for exactly the same but it sticks around still.

Back up your data folks. You're probably more likely to accidentally rm -rf yourself than download a script that will do it.

Well yeah ... the native package manager. Has the bonus of the installed files being tracked.

I dont just cringe, I open a bug report. You can be the change to fix this.

Those just don't get installed. I refuse to install stuff that way. It's to reminiscent of installing stuff on windows. "Pssst, hey bud, want to run this totally safe executable on your PC? It won't do anything bad. Pinky promise". Ain't happening.

The only exception I make is for nix on non-nixos machines because thwt bootstraps everything and I've read that script a few times.

Anti Commercial-AI license

When I modded some subreddits I had an automod rule that would target curl-bash pipes in comments and posts, and remove them. I took a fair bit of heat over that, but I wasn't backing down.

I had a lot of respect for Tteck and had a couple discussions with him about that and why I was doing that. I saw that eventually he put a notice up that pretty much said what I did about understanding what a script does, and how the URL you use can be pointed to something else entirely long after the commandline is posted.