What is wrong with curl | sh with HTTPS?
Linux does essentially the same thing with GPG signatures instead.
Linux does essentially the same thing with GPG signatures instead.
https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
Almost no one actually audits the source they download before they run it, whether it be a package installer, a configure/make/make-install tarball, or a curl|sh.
If you know enough to audit a shellscript, you can easily decompose the command-line to download, audit, and run the local copy.
For the vast majority that chooses to simply trust the author, there is no additional security issue with curl|sh compared to other non-signed distribution methods provided the script is wrapped in a function call or otherwise resistant to errors that might happen if a partial download is executed.
Should we do better than curl|sh? Yes. But it's no worse than downloading some random tarball or even cloning some random git repository, as long as it's served over HTTPS.
Thats not the security issue here, its effectively running build-time logic during install-time, on every bodies machine at every install, instead of at package maintainers secure build system, once, and having the installation basically be an unpack instruction.
Another negative point of curl | bash, is you assume your users are idiots who do not know their OS package manager well enough to run apt-get install shitpackage pacman -S shitpackage or apk add shitpackage.
Absolutely, but packaging for all major distributions can be a larger headache than writing the project in the first place. For a lot of small projects, this isn't justifiable.
Edit: I cooked up an example actually. Here is a small Go program that will panic after 1 nanosecond: https://gist.github.com/kyleterry/dc304503dfca2d149b189694d1...
This will sometimes return partial responses.
Run this in a bash `while true` loop and curl localhost:8080 a few times. You will mostly see empty and full responses because my example isn't perfect, but occasionally you will only get part of the script dumped to the screen and that's the problem with curl|bash.
function f {
echo "hello world"
}
fIf your GPG signature is in your keychain, it's safer anyway.
HTTPS by itself does not protect against malicious content or malicious actors (DigiNotar, TurkTrust, GCHQ, ...)
That isn't to say that it isn't the product of a targeted trojan signed with a stolen GPG key.
That you may unwittingly opening up your machine to vulnerabilities.
Most sophisticated people won't execute remote scripts from untrusted sources, but as more people switch to unix-like operating systems, they may have as much scrutiny.
A designer on my team was given a mac, and if a script failed to run locally, he would immediately re-run the script using `sudo.` I can't imagine he was the only person to use this solution.
Ive yet to see a "curl https://thisshit.net/trust/us/really/we/have/https | bash" script which didnt fail for whatever dumb reason, such as only working on specific variants of Ubuntu, with specific packages installed in specific version, and/or RedHat.
Usually these shit scripts fail when trying them out, for curiosity, in ArchLinux, Gentoo or Alpine Linux.
Sandstorm.io looking at you.
If you are already going to invest in making "an install script" with defined/researched which packages/versions with which your software needs, for various platforms - submit this data to that platform as an debian/{control,etc} to make a .deb or specfile for .rpm or PKGBUILD or whatever, and use the platforms _build tools_ to generate a platform specific package - be a package mantainer if you have to.
Another side effect of telling your users to curl | bash, is I wont ever use your software. You didnt make the effort to do the right thing with packaging, why would you have done any better for whatever it is youre trying to do with your shit software? (sandstorm again).
When I have to install packages from source, I have a more secure/locked down linux container, with seccomp applied, dropped capabilities etc, then if I intend to use the the software over longer time, and expect updates, I skim the source and build-system quality, quickly write a PKGBUILD or APKBUILD, build it, install it into its own new container - with iptables filtering outgoing connections, and thats it, sometimes submit the APKBUILD to alpine testing or aur.
And all this is easier than curl | bash oh watch it fail for dumb reason in the install script - and I did try that, the time spent troubleshooting the install script is longer than time to sandbox the whole thing as described above.
So, if I can do it, why cant the project? Why spend their efforts on writing an install script instead of package-build instructions to various distributions?
(I am a Sandstorm fan, but I don't have it installed because it wants me to flip some sysctl about user namespaces or something, and I don't currently have a separate machine to do that on)
FWIW, this is no longer needed! Sandstorm has been updated to work without user namespaces and this installer script change will remove the check from the installer (will probably ship this week):
https://github.com/sandstorm-io/sandstorm/pull/2656
(You will need to let Sandstorm start as root if you don't want to flip the sysctl, though.)
Joke of today, thanks for the laugh.
If it's a single-user machine, any process running at any privilege level can trivially get root by editing ~/.bashrc and aliasing the sudo command.
I dont even have sudo, let alone if I had it, I wouldnt use its dumb caching of credentials/session or "ask no password" "feature".
Just because my system is single-user doesnt mean I run every process with that one user, in fact I run firefox as its own user, chrome has its own, mpd as its own user, nginx is its own user and so on. This is basic security practice.
If you seriously think that it is so easy to get root just because you can run a process as a normal user - "by aliasing sudo command", then by all means run everything as root, whats the harm or big deal, right? Why do you even have a user which is non-root?
Why cant sandstorm run like lighttpd or nginx - as their own user, requiring no capabilites, in fact even syscalls can be revoked from them with seccomp and they will still work fine. All they need is socket api, file system api ( open close create), and some others, no they dont need to load kernel modules, ptrace or open_file_handle_at and so on.
Sandstorm works exactly the same way.
nginx can run as completely non-root, if you are OK with high-numbered ports.
Sandstorm can too, if you are OK with high-numbered ports and if unprivileged user namespaces are enabled.
(It sounds like you actually use UID separation for security on a desktop. That's cool, although keep in mind that if everything is talking to the same X server, then UID separation probably doesn't help much. If you're serious about this approach you should probably be using QubesOS.)
Projects that recommend piping curl to bash are trying to dumb down the process, and they have a tendency to make too many assumptions about the system it'll be running on.
such as only working on specific variants of Ubuntu,
with specific packages installed in specific version,
and/or RedHat
submit this data to that platform as an
debian/{control,etc} to make a .deb or specfile for
.rpm or PKGBUILD or whatever, and use the platforms
_build tools_ to generate a platform specific package
- be a package mantainer if you have to
Another side effect of telling your users to curl | bash,
is I wont ever use your software. You didnt make the
effort to do the right thing with packaging, why would
you have done any better for whatever it is youre trying
to do with your shit software?
[1] https://developers.google.com/speed/pagespeed/module/build_n...
So you dirty the system where its supposed to be installed, a server, with gcc, make and friends?
> . If you're running something else it prints out "This doesn't appea
State so on your documentation/page before telling the user curl | bash, as I wrote in another post here, that is nice.
Your script does not support transactionional installations, as it is it can break at any point in the script and leave the target system broken/dirty. With a simple PKGBUILD youd also have solved the "binary ABI" part. If it really is tedious to coordinate with several distros, you can take a shortcut and dont deliver a "pkgspeed-for_nginx_module-1.2.3@v1.2" package but instead a "pkgspeed-1.2.3" which conflicts with the normal nginx package and thats it.
So you dirty the system where its supposed to be
installed, a server, with gcc, make and friends?
State so on your documentation/page before telling the
user curl | bash
Your script does not support transactional
installations, as it is it can break at any point
in the script leave the target system broken/dirty
No. That is not how nginx is traditionally installed.
You misunderstand basic Linux package management and build systems, which is why you end up in this mess. But thats okay, world is keepin on spinnin. To each their own.
> Sandstorm.io looking at you.
That's hardly fair, since the reason the Sandstorm installer fails on Arch is because it explicitly checks for the presence of a required kernel feature, and Arch explicitly doesn't have that feature. The installer script fails intentionally because of the missing feature, not because it is badly written. Shipping an Arch package wouldn't have magically made Sandstorm be able to work without the required kernel features. OTOH, if you build a custom kernel that has the necessary features, the Sandstorm installer will run just fine on Arch.
(Coincidentally, we plan to lift this restriction this week, as we recently implemented an alternate sandbox design which doesn't require this feature.)
In any case, I doubt your sandbox today would work in my sandbox.
That is kind of the point, why cant you ship an application which runs as a normal user only, why do you require root for everything and assume your sandstorm will be the machine-manager? Last time I tried, you actually recommended curl shit | sudo bash. sudo! Nevermind I hate sudo and dont have it.
If you need sudo, take it/ask for it, specifically for that 1 operation, not for whole install script. Maybe thats how its done today?
No it wasn't. The install script ran a little program that actually attempted to invoke the system call to see if it failed:
https://github.com/sandstorm-io/sandstorm/blob/800d1c016c150...
We have never relied on /etc/lsb-release nor /proc/config.
> why cant you ship an application which runs as a normal user only
First, we're not shipping an application, we're shipping an application platform which includes a container engine.
On systems that have unprivileged user namespaces available, you actually can install and run Sandstorm as a regular user -- no root privileges at all.
Unfortunately, Arch explicitly turns off user namespaces in their kernel build.
Without user namespaces, we have no choice but to require root privileges, because the Linux system calls for setting up containers require either root or user namespaces. (Note that Sandstorm is careful with its root privs -- most of the system runs as a regular user, calling out to a separate daemon for the specific operations that need root.)
If you don't want to give Sandstorm root -- which is perfectly understandable -- and you don't want to enable the kernel features that allow it to be non-root, then you'll need to run it in a dedicated VM.
> Last time I tried, you actually recommended curl shit | sudo bash.
We have never recommended that.