14 ms·
As opposed to the Linux security best practices of curl | bash? I have no choice but to set up my computer to run untrusted code, on a CPU which itself might be
by dj_mc_merlin 3y ago
As opposed to the Linux security best practices of curl | bash? I have no choice but to set up my computer to run untrusted code, on a CPU which itself might be spying on me -- I don't feel like my environment is inherently more secure than Windows at all. Just less popular.
- pxc 3y ago> the Linux security best practices of curl | bash? You do realize that even this is the same as downloading and running an executable from a website, which is still the norm on Windows, right?
- xigoi 3y agoIn fact, curl | bash is safer, because you can replace "| bash" with "| less" and inspect the script.
- xmodem 3y agoI would argue that Windows checking certificate signatures provides a lot more safety to the vast majority of users than manually inspecting a bash script.
- xmcqdpt2 3y agohttps://news.ycombinator.com/item?id=17636032 https://news.ycombinator.com/item?id=17636032
- pxc 3y agoYeah, you don't actually want to pipe to less and then rerun piped to bash because it's vulnerable to a TOCTOU problem. You want to save it the first time, then read it in your editor. When you distribute those scripts around your org, you also want to verify them with a sha256 hash or something like that. This is what I do for installers I use this way and other software downloaded over HTTPS at work. I also generally avoid installers that download other installers. If you've got a script that downloads platform-specific installers, you may prefer to write out specific instructions for each platform and download the platform-specific binaries directly. A shell installer like this running curl is a red flag imo.
- robertlagrant 3y agoA CPU that might be spying on you isn't to do with malware. This is about the difference between OSes, which is worth talking about in and of itself.
- mcpackieh 3y ago> the Linux security best practices of curl | bash? 1. Widely criticized. 2. Not something the OS does, or even encourages. The OS permits it in the same way that the OS permits you to set your root password to hunter2 and run telnetd. You can't, and shouldn't, stop people from deliberately screwing themselves.
- jaywalk 3y agoHow do you know my root password? Delete this.
- bch 3y agoWhat is it? I only see “*******”.
- ghostpepper 3y agoContext for the uninitiated http://bash.org/?244321 http://bash.org/?244321
- DaiPlusPlus 3y agolol, yes. See, when YOU type hunter2, it shows to us as ****
- ChuckNorris89 3y agoIndeed. If you think Linux is inherently more secure than Windows, then I dare you to curl/wget some random sh script and run it as root.
- mcpackieh 3y agoMake sure to also test the safety of a spoon by scooping your eye out with it.
- revolvingocelot 3y agoBut isn't installation via curl more of a PEBKAC issue? You don't have to pipe it to a shell immediately -- pretty sure you could curl the install script and manually verify it. And isn't the CPU-might-be-spying an invariant? One certainly cannot change how one feels about one's security, but those don't seem to be reasons Linux is inherently more or less secure than Windows...
- Asmod4n 3y agoThe security practice on windows is to click yes on any prompt shown to you.
- chx 3y agoThat's not just Windows, someone had a presentation I think from Mozilla showing people can't make heads or tails of the SSL certificate error window and consider the whole thing to be "click yes to get on with things". Found it: https://inoio.de/images/something-happened.jpg https://inoio.de/images/something-happened.jpg could be from https://www.usenix.org/sites/default/files/conference/protected-files/enigma_slides_smith.pdf https://www.usenix.org/sites/default/files/conference/protec...
- wepple 3y agoThere are a bunch of bad legacy technologies still baked into windows for which I can’t see a non-windows equivalent For example: credential hashes. They can be used as a bearer-token, and a privileged enough one can log into absolutely any system in the entire domain and do anything.
- kbenson 3y ago> As opposed to the Linux security best practices of curl | bash? Just because some people like to ask you to install their software that way doesn't make it "Linux security best practices" and it doesn't mean you need to follow those directions. You can review whatever you're running, and you should if you want to install that way and feel it's insecure. At a minimum you can download the script to an actual file you keep around for a while and run it, so if something weird does seem to be happening you can at least see what the script was attempting. Or, just refuse to install software that way. There's almost always a different way, and that's just provided for convenience. If people are opting for the unsafe method because it's convenient, I don't think that says as much about the OS as it does the people using it.
- the_af 3y agoI don't disagree with what you're saying, but: > You can review whatever you're running How realistic is this for regular users? And even power users, in some cases. Let's say you download the install script. It's either hundreds of lines or it in turn downloads and runs some blob. Are you comfortable asserting your review is enough? Is this truly so different to clicking on some random Windows installer? If the same kind of Windows non-power users start running Linux and it becomes a really widespread desktop OS, would the situation be particularly different?
- nephanth 3y agoDo regular users `curl|bash`? From my experience that's a pretty rare occurence: stuff users need is generally in the repos
- the_af 3y ago> Do regular users `curl|bash`? They don't (unless following instructions). But that's my point: downloading stuff and "reviewing" it is not feasible except for power users -- which are not the scenario we're describing -- and not even then! Can you tell me you trust yourself to review a non-trivial install script? > stuff users need is generally in the repos Even games? If we're talking about regular users, they'll want to play games and other things not packaged with their repo.
- deleted 3y ago[deleted]
- gkbrk 3y ago> Linux security best practices of curl | bash I don't know who tells you about Linux security, but you should replace them. The best practice for installing software on Linux is to use the package manager and install from the repositories of your Linux distro, or trusted software vendors.
- mcpackieh 3y ago> The best practice for installing software on Linux is to use the package manager Bingo. In Windows and even MacOS, it is normalized behavior to download and run software with your web browser. Want VLC? Google for VLC then maybe end up on a website like sourcef*rge that adds malware to the installer. On Linux, this sort of workflow is possible and permitted, but not encouraged. Instead users are encouraged to only install software through their package manager. I can leave my dad with a Xubuntu install and trust him to not download malware because I taught him how to use the package manager, and warned him against trying to download software with his browser as though he were using Windows. 15 years like this and he still hasn't messed it up. With Windows he had new malware every week. Downloading and running strange software off the web is normal windows culture and windows scarcely even provides a better alternative to it. (The "Windows Store" is an improvement to this situation I guess, but from what I understand most software available through it isn't free. This means windows users are incentivized to fall back on old habits and go scrounging around on the web for free binaries to blindly run.)
- Macha 3y agoMorally curl | bash is no different to downloading a package from the provider directly, or adding a repository managed by the provider. As people are well aware, it will not protect you from the software provider being malicious. Neither will obtaining that proprietary installer from adobe.com for Windows/Mac. I'd argue the security level goes from worst to best: 1. curl | bash = npm/pip/cargo/whatever install = developer provided package repositories = proprietary software installers 2. App stores from proprietary OS vendors. You still don't really know what's in the software, but at least you already have to trust Apple/Microsoft if you're using those OSes and they can remove detected bad behaviour globally. 3. Package repositories from trusted traditional linux repositories. You can view the purported source code of the build, plus there is now someone who can block bad packages. 4. Package repositories from linux repositories with public build processes. Not just the scripts, but being able to see the execution of the build and have it signed to prove where it came from (as opposed to Joe packager's personal machine then FTPing it up). 5. Making your own copy of every piece of software, auditing the entire source code, building it in an environment you control, and keeping the artifact you then sign somewhere you control. This is so much work that nobody does this. People like to tut tut at curl | bash, but most of them are happy to do everything else in line 1, and maybe trust line 2. This is not the position of safety and moral superiority it's portrayed as.
- tracker1 3y ago6. use flatpak/snap/appimage that run in relative isolation from the core os.
- Macha 3y agoFlatpak itself is really a different dimension of security to that discussed here. It solves a different problem (the software might have exploitable security vulnerabilities) than the one discussed here (the software itself might be malicious). Running software that secretly phones home everything you do in the program is still going to be a problem in flatpak.
- sigotirandolas 3y ago
- causi 3y agoLinux security will never stop feeling weird to me. Like when I try to do something that needs to be started with sudo, instead of warning me and just asking me if I want to run the command as root, I have to go back and input it again with sudo. Then some programs like VLC just straight-up refuse to run as root.
- dsr_ 3y agoThose are two great things for security that prevent you from: $ rm -rf * No permissions in this directory - want to try with sudo? (Y/n)
- ElectricalUnion 3y ago> Like when I try to do something that needs to be started with sudo, instead of warning me and just asking me if I want to run the command as root, I have to go back and input it again with sudo. This sounds like a misconfiguration or lack of support for policykit to me. > Then some programs like VLC just straight-up refuse to run as root. That IMHO should be the standard behaviour of most non-basic/GUI programs to me, running as root is overall a terrible idea.
- jchw 3y agoWorrying about the security of curl | bash when talking about an operating system where the modus operandi for installing software was downloading closed-source and often obfuscated binaries from random websites and running them is insane.
- olyjohn 3y agoHonestly, I feel like more people have been infected with malware from App Stores than from downloading and executing shit from random websites. Even Warez sites from back in the day were more trustworthy. Cuz if you download from a random site, you might think twice about what it is, is the source trustworthy, etc? But the App Store, well Apple and Google tell me it's 100% safe, so just download all kinds of trash.
- MattPalmer1086 3y agoFor mobile app stores you are right, but only because they are the ONLY place most people will obtain software for their device from. You don't download binaries and install them from web sites on Android or Apple. For desktop operating systems, I think you are probably wrong. Downloading and installing binaries from web sites is a huge cause of malware infection. And warez sites were not trustworthy at any time. I doubt much malware has been installed via Linux package managers or by the Windows app store (if anyone actually uses that).
- mcpackieh 3y agoBrowser extension 'stores' are terrible too. Both Google's and Mozilla's. On the other hand, I do trust F-Droid. The vetting of ideological motivated volunteers beats the vetting of disinterested corporations.
- jrm4 3y agoThis an absurd example; ironically what makes it 'safer' in reality is that the only people who use it know how dangerous it theoretically could be, and thus are able to reason about its source. How often has curl | bash ACTUALLY been a vector for problems?
- safety1st 3y agoOh this is balderdash. Firstly if it's curl | bash you actually do have the choice to download the script before running it and review its contents. Secondly most software on Linux is not installed this way - it's installed through the distro's package manager, flathub, Steam etc. where it actually is way more vetted than a random download. Of course you can install random downloaded appimages etc. if you want as well because this is Linux and it doesn't treat you like a child in a sandbox, you own your system, you do what you want with it. Which gets to my last point - the software which is installed through curl | bash is generally targeting developers and frankly, as a developer, you should know what you're doing. You take the risk where the risk is small (on your throwaway dev VM), you vet & review the code first where the risk is real (on a production server or something). Your comment was counterfactual nonsense
- reidrac 3y agoYou are supposed to run software packaged by your distribution, and that's trusted. The curl | bash is bad practice and shouldn't be used. You have way more control and security using a Linux distribution. The objectives of that and Windows are completely different, and that affects user's security.
- pmarreck 3y ago> As opposed to the Linux security best practices of curl | bash? This comparison would only be valid if almost everything you install on Windows was at least theoretically inspectable before installation, instead of, well, almost nothing. LOL, nice cope. Anyway, here's a Bash function you can add to your dotfiles to add confirmation to that sort of "workflow": confirm() { tmpfile=$(mktemp) # use tee to split stdin to stderr and the temporary file tee "$tmpfile" >&2 echo >&2 # Prompt the user. >&2 read -p "Do you want to pass this code along? [Y/n] " response < /dev/tty case "$response" in [nN]*) echo "Operation cancelled." >&2 rm "$tmpfile" exit 1 ;; *) echo "Proceeding..." >&2 cat "$tmpfile" rm "$tmpfile" ;; esac } Now you can just take those one-shot install lines and stick this "confirm" function in the pipe like so: curl <url> | confirm | bash ... There's probably a slicker way to do this, if you're super into Bash. And you may want to `set -o pipefail` in general, so that the "exit" code of 1 actually gets seen...
- michaelmrose 3y agoAverage security is what is easy and common(usually because its easy). It's common for regular users to install via their software center where they will find their office software, browser, and other common apps. It's common for some developer oriented software to list a lazy way to install software from a trusted source. They also aren't running curl $URL | bash on a $URL from a scam email they just got. It is indeed bad practice but its a relatively contained bad practice and its not reasonable to compare this situation where some developer oriented software recommends a controllable insecure method with the common user experience of hundreds of millions of windows users constantly installing all software by downloading and clicking on executable the functional equivalent of curl|bash
- ilyt 3y agoLinux best practice is to download package off signed repository, curl|bash is JS bros sniffing glue again
- throwbadubadu 3y ago"Best practice" is a bit exaggerated.. or tbh a joke. Any reasonable software I have lately seen distributing that way (and that were few ones) usually come with disclaimers like "beware that you must trust us" or pointing to alternatives in the direction of package managers.. > to run untrusted code, No again, that depends on who you trust, right? If you trust noone, it is all up to you, certainly.. and at least you have the theoretical possibility to review almost everything (which other people actually do).
- eptcyka 3y agoYou can curl into bash all you want, but how's that better than just running an Installer.exe ? Most software I install on Linux is at least somewhat verified by a maintainer to be sane, there are no maintainers on Windows, just HTTPS servers with binaries.
- ajross 3y ago> As opposed to the Linux security best practices of curl | bash? Gotta take offense here. That's a MacOS paradigm. All Linux distros have proper package management, always cryptographically signed and increasingly reproducibly verified, and extremely broad coverage of virtually all the software in the community. The closest you get to this kind of thing as an "official install mechanism" is e.g. bootstrapping a package repo for third party software, which has you hand-verify the keys. People who pull unverified code to their boxes are virtually all developers cloning stuff to build.
- mr_toad 3y ago> As opposed to the Linux security best practices of curl | bash? At the time Windows had far worse vulnerabilities than running untrusted code. You didn’t need to download or run anything, just connecting to the internet without a firewall (which was common in the dial-up era) exposed services that could be exploited by a remote attacker.
- deleted 3y ago[deleted]
- nullc 3y ago> As opposed to the Linux security best practices of curl | bash? the only thing I can recall asking me to do that is rust... (which tracks, as the rust ecosystem seems to have decided that the only kind of safety that matters is memory safety :) ).
- sersi 3y agoI've never ran curl | bash once and I use linux fairly regularly in the past 20 years. If I absolutely have to install something where the only way is to pipe a curl to bash (which is incredibly rare), I first download the script, review it and only then execute it. Doing curl | bash is absolutely not security best practice.
- zzo38computer 3y agoAlthough curl|bash seems to be common, I don't like that and I don't do it. If I need that (rather than just using the package manager), I will first save it to a file (I still usually use curl for this, but will not pipe it directly into bash since that is too insecure), and then possibly modify the file if I want to do. However, such a thing should usually not be needed, if you use package managers or run programs under emulation or download and compile the source yourself (possibly after reading it if you are concerned about it; I use a non-Unicode locale for further security when doing this), etc. The CPU spying is more of a real problem, though.
- lobocinza 3y agoThat's not true. wget is more popular for this. And trusting PGP keys of random dudes adds an additional layer of (in)security.