upvote

points

by sinsudo5 hours ago |
comments
upvoteby throwaway73562 hours ago|
next
[-]
Yeah, works well:

$ /usr/bin/sudo() { echo Not the real sudo.; }

$ /usr/bin/sudo

Not the real sudo.

And every other suggestion also doesn't work if the attacker can just replace the shell.

reply
upvoteby 1 hours ago|
parent|
next
[-]
deleted
reply
upvoteby anthk1 hours ago|
parent|
prev|
[-]
/usr/bin/sudo isn't evaluated as a function under ksh.
reply
upvoteby mort964 hours ago|
prev|
next
[-]
Yes, that would be one potential solution. But I have certainly never done it and bet >99.999% of the world's use of sudo is through 'sudo'.

Plus you only need one slip-up and you're hosed. Even people who try to almost always use '/usr/bin/sudo' will undoubtedly accidentally let a 'sudo' go through. Maybe they copy/paste a command from somewhere (after verifying that it's safe of course) and just didn't think of the sudo issue then and there.

reply
upvoteby sinsudo4 hours ago|
parent|
[-]
The real problem is that there should be at least 2 levels for sudo, one for installing software and another that really allows someone to compromise the entire system, both layers should be separate to mitigate risk. At least the most secure layer should allow you to perform secure recovering and diagnosis
reply
upvoteby DaSHacka1 hours ago|
parent|
next
[-]
More than just two levels for sudo, the Linux permission model is completely broken for this very reason. (Also see: https://xkcd.com/1200/)

Honestly, the Android approach is significantly better. (and for that, see Micay's various ramblings posted online)

reply
upvoteby lrvick3 hours ago|
parent|
prev|
next
[-]
You do not need sudo for installing software. Can just install to ~/.local.

Many package managers require sudo, sure, but there is no good reason for them to in a modern linux system, and not all require this.

Even with systemd, you can use systemd --user.

reply
upvoteby michaelmior2 hours ago|
parent|
[-]
That depends on what the software is. If you want to run a service that bonds to a privileged port for example, you need sudo.
reply
upvoteby lrvick1 hours ago|
parent|
next
[-]
If you set the appropriate linux capabilities flag on a binary such as sshd at bootup then unprivileged users can bind to 22, no problem.

setcap 'cap_net_bind_service=+ep' /usr/sbin/sshd

Could even run it as a daemon unprivileged from a home directory with "systemd --user"

That said if you have multiple users and want every user to have their own sshd reachable on port 22 on the same machine you probably want to listen on vhost namespaced unix sockets and have something like haproxy listen on port 22 instead. Haproxy could of course also run unprivileged provided it has read access to all the sockets.

reply
upvoteby zrm1 hours ago|
parent|
prev|
next
[-]
For that you really only need CAP_NET_BIND_SERVICE.

The bigger issue is that if you want to install or update system-wide packages, many of those will be used by privileged processes. Suppose you want to update /bin/sh. Even if the only permission you had is to write binaries, that'll get you root.

reply
upvoteby signed-log1 hours ago|
parent|
prev|
[-]
For most things, you can do with capabilities

Issue is that it increases friction and you need sudo anyways to set the capabilities.

Most web servers would happy to run unprivileged with only CAP_NET_BIND_SERVICE

reply
upvoteby DonHopkins3 hours ago|
parent|
prev|
[-]
Unix used to have a user named "bin" just for owning all the binaries and performing installs.
reply
upvoteby sinsudo3 hours ago|
parent|
[-]
The old bin user is an idea that could be modernized with a new two level sudo concept, the higher one for recovery and diagnosis, already done in Chromebook and other solutions
reply
upvoteby DonHopkins1 hours ago|
parent|
[-]
bin passwords I will always remember: At the University of Maryland CS department systems the bin password was "fuck,you", and there was a devout Christian student on staff who had a problem with that, so we had to change it (to something harder to remember, I just can't recall).
reply
upvoteby ChocolateGod2 hours ago|
prev|
next
[-]
Surely if malware has rw access to the home folder, it can adjust the env variables / shell to make this also fake.
reply
upvoteby exyi4 hours ago|
prev|
next
[-]
Ok, so the malware runs a keylogger / clipboard logger, gets the password and runs sudo on it's own. Or replaces your shell by putting exec ~/hackedbash into your bashrc

Password on sudo is only useful if you detect the infection before you run sudo

reply
upvoteby fragmede3 hours ago|
parent|
[-]
Could link it to a yubikey via pam.d so you need a fingerpress to authenticate.
reply
upvoteby pastage3 hours ago|
parent|
next
[-]
Physical attestations are hard to solve, I think it would be nice if all TPMs in laptops had this. Then the problem becomes how do you automate stuff that needs to be done.
reply
upvoteby lrvick3 hours ago|
parent|
prev|
[-]
And then the moment you authenticate, the fake sudo still executes its payload.

Yubikeys do not fix this issue.

reply
upvoteby eviks4 hours ago|
prev|
[-]
Why not make a proper link /sudo so you don't have to type out the full path every time, which is very inconvenient? (but the fact that such workarounds are needed still means it's a theater)
reply
upvoteby lrvick3 hours ago|
parent|
next
[-]
A simple LD_PRELOAD command can cause your shell to run "rm -rf /" when you type "/sudo".

If your unprivileged user is compromised, you are pretty hosed.

reply
upvoteby anthk1 hours ago|
parent|
[-]
It should be a way to make system env vars (profile.d or simlar) as readonly so every users' shell had these set to empty values and unable to change them.
reply
upvoteby sinsudo3 hours ago|
parent|
prev|
[-]
Anything that can be modified by an attacker can not be used to secure the sudo command. This is a recursive requirementor hierarchy for secure systems.
reply
upvoteby eviks2 hours ago|
parent|
[-]
You can set the permissions so that the attacker can't modify it?
reply