Follow

Oh. And before any of you lay any blame on the maintainers of these open source project.

How many of you have blindly installed stuff by running curl | sudo bash ?

Did you verify the binaries and the code the bash script ran/installed? How did you confirm trust on those binaries?

Xz is the oss supply chain attack we know about. You can guarantee there are many many more. How we manage installation, and dependency's should perhaps have a little more thought...

· · Web · 1 · 3 · 12

@quixoticgeek `curl | sudo bash` is horrifying on so many levels. Projects that suggest this as an install method are immediately suspect to me.

While I'm on a rant, the Ubuntu style "sudo for everything from the default user account" is disturbing as well. Day-to-day user accounts should NOT have root access, full stop.

@allpoints @quixoticgeek to be fair in Ubuntu you can control which users have sudo access. So if you're security minded you can turn that off.

There's probably a better option that has something that lets users add/remove packages but doesn't have all the other privileges.

It's not much effort, but you don't want everyone to be able to do su root

@themself @quixoticgeek yes, you absolutely can configure sudo access. But the default Ubuntu install automatically gives full access to the user account it creates on install. It could, e.g. create a separate "admin" acct. It's why you see tutorials that prepend every command with `sudo`

Re configuring sudo. Heads up systemd breaks the use of 'localhost' in the config file as it no longer maps back to 127.0.0.1

@allpoints @themself the defaults with sudo suck. Even worse are the systems where sudo doesn't even need a password. I don't understand the point of having to put sudo in front of a command, but not ask for a password seems pointless.

@quixoticgeek @allpoints agree on the defaults aren't secure. I also don't get why you wouldn't prompt for a password, that's so crazy that you may as well not bother with sudo!

@allpoints @quixoticgeek I don't want to manage multiple accounts on a computer only I use.

The default configuration is good enough. Nobody is able to do anything without knowing my password.

@dusnm @allpoints if you're just sticking sudo in front of the command and having no further authentication, what exactly is the purpose of sudo.

@quixoticgeek@social.v.st @dusnm@fosstodon.org @allpoints@mstdn.social Simon says. Which seems fine as a simple check that you really mean to make a system-level change, rather than a security measure.

Seems better than doing things that don't need to be root (eg. decompressing and compiling things) in a root shell, anyway.

@kim @allpoints @dusnm except you then find people just putting sudo in front of everything... At least the password adds an extra check. Type it on every command and you're not gonna use it when it's not needed

@quixoticgeek@social.v.st @allpoints@mstdn.social @dusnm@fosstodon.org repeatedly typing a password would appear to be equivalent to repeatedly just typing "sudo " for those purposes. Except with more risk that your password ends up in your .bash_history

(Though to be fair, I have usually have sudo configured to prompt me for a password.)

@dusnm @quixoticgeek The smart approach to security is layers. It's much easier to compromise an everyday account. Giving that account and its password root access is a bad idea.

But it's your machine and you get to choose where the line is between ease of use and security.

IMO a major problem with the Ubuntu approach is they've trained new users to type `sudo` in front of every command without thinking about it. These are the same folks who don't understand why `curl | sudo bash` is bad.

@allpoints @dusnm at one job, colleague complained that I didn't include sudo with commands in documentation, instead having a # or $ for the prompt to tell if iy needed sudo/root. That way people didn't just copy paste stuff without knowing what they were doing.

@quixoticgeek @dusnm

"That way people didn't just copy paste stuff without knowing what they were doing."

Personal systems are one thing but I would be concerned if I had colleagues with root access who cut/paste commands without understanding when/why root level access is required.

@allpoints @quixoticgeek sudo/curl gets a lot of unjustified flak though.
You need root to install a deb or rpm or whatever package just as well. And the pre-/post install scripts in those are less visible if anything.

@felixf @quixoticgeek sorry, it deserves all the flack it gets. I don't have a problem at all with an install script. But the instructions aren't "download this, look it over and run it as root."

And yes, packages require root access and run scripts. However I have some trust/faith/hope the package maintainers have done their job well.

The fact is curl/sudo has a bad smell to it and makes me distrust the projects that suggest it.

@allpoints @quixoticgeek what inspires that trust/faith/hope?

Why don’t you expect instructions to first decompile the package and check its scripts?

@felixf @quixoticgeek to answer your 2nd question 1st, because I have a life and don't have the time/interest to do that.

If it's not apparent why I have more faith in a package from my chosen distro or from a project that understands and has taken the time to build one then I'm not sure we have a common enough framework to have a fruitful discussion

@allpoints @quixoticgeek fair enough, but curl/sudo installers don’t replace distribution packages. They replace upstream apt/yum repos. And I maintain that the surplus trust that people put in the latter is mostly undeserved.

@felixf @quixoticgeek re undeserved, I suppose that depends on the package and the reputation of the repo but I understand and can even agree with your point

@felixf @allpoints aside from all the other issues with curl|bash, they often don't come with an uninstall function.

Sign in to participate in the conversation
(void *) social site

(void*)