List of Unix binaries that can be used to bypass local security restrictions

Yes, good question.

Because su was there in Unix before sudo, IIRC. And sudo means "su do", meaning do (something) as su, which in turn meant "super user" or "substitute user" according to Wikipedia, since it can also be used to login as other users than root , e.g.:

su - tom

https://en.m.wikipedia.org/wiki/Su_(Unix)

Yeah, that's the classic https://xkcd.com/1200/

I thought about using Qubes OS on my new computer but it seemed like a lot of work and tweaking and still having to live with the limitations so I abandoned the idea.

Probably not 99%, no. It may be worth noting that macOS doesn't have these issues. The password manager doesn't run as the user, and entries in it have ACLs that restrict which apps can read them. In turn that's enforced by the kernel: apps can't ptrace each other and they can't tamper with each other's files. Browsers, meanwhile, encrypt the cookie store using a key stored in the keychain, so you can't read the user's cookies either.

All this is true without app sandboxing being activated. Apps that are sandboxed get even more protections.

Apple have done the best job of incrementally isolating apps from each other using different levels of sandboxing. Linux and Windows are far behind even with Flatpak. For example, we tell people who use Conveyor (our product for deploying desktop apps [1]) that one of the most secure platforms to do signing on is a Mac laptop, because the signing keys can be protected such that only Conveyor itself can read them. Even if you execute malware, it would trigger a permission prompt if it tried to access the signing keys, and then the process doing the signing is also protected in the same way. To get the same effect on Linux you'd need to set up dedicated UNIX users and the like.

Maybe I should write up a blog post on this stuff. Apple tighten things incrementally with each major release and don't make much noise about it, so I've found a lot of people aren't aware of how advanced their security has actually become.

[1] https://hydraulic.dev/

I see that reasoning very often but I don't agree with it (note that I'm not saying a local exploit is great).

But first I'll start with a question: why don't you (and everybody else for that matter), run everything as root?

Why don't we all search our entire disks for every single executable and then execute chmod 777 on all of them? I mean: that'd make for a good XKCD...

If the idea is that it's game over anyway if there's a local exploit, we may as well just run everything as root right? Why even bother with sudo at all?

> Out of curiosity: What sensitive things does the root account protect on your workstation?

I'm one of those person using several user accounts on my own system. For example my professional account is separated from my personal account (and I do use both simultaneously). One of my browsers (I run several browsers) is in a throwaway user account: clean slate at every launch. Why not?

And a local exploit compromising one user account requires a second exploit to access what's in the other users accounts.

> The only thing root access would give somebody on my machine is to uninstall some random packages or corrupt my install.

Root access could allow the attacker to install a persistent backdoor which would be very hard to detect. Installing a persistent backdoor that can evade detection is incredibly harder to do if all you have is a local exploit.

I take a system on which I have more chances to detect that an exploit happened --even if the exploit did already happen-- any day over one with less chances to detect that an exploit happened.

And even if, for me, a local exploit means it may be too late for some stuff (although having U2F/webauthn and soon passkeys in many important places should limit damages), having a non-compromised root may allow me to detect a local exploit and share my findings with the community. Which has a lot of value too.

Mostly:

* Logs: If my unprivileged user gets compromised, there's a much better chance that I can figure out what the attacker did if he can't wipe his traces as root.

* Money: I use a different unprivileged user for general use and for banking, so a compromise of my general purpose user doesn't immediately mean that my banking stuff gets compromised.

* Lateral escalation: Similarly I use another user to verify the checksums or PGP signatures of Windows/Linux images, so I don't end up booting a compromised image even if I download it from a compromised browser.

The ptrace issue you mention can be avoided by using the Yama LSM.

You mention that you tried Flakpak for isolation. If you set up a well-protected root account, along with multiple unprivileged users, you can also get isolation, but between different security contexts rather than different applications. It is less convenient than Flatpak for daily use, but is extremely mature and doesn't require any of the extra layers (user namespaces, bind mounts, proxies...) that Flatpak uses.

> The only thing root access would give somebody on my machine is to uninstall some random packages or corrupt my install.

While I agree that compromise of an unprivileged account has significant costs, technically superusers do have significantly greater access to the system and so there are greater levels of risk.

RedoxOS is reimplementing Linux userspace utilities in rust in order to avoid C vulns in suid binaries; like ping, which requires raw sockets for ICMP (which most of us only need the Echo Request capability of)

Superuser: https://en.wikipedia.org/wiki/Superuser

Capability-based security: https://en.wikipedia.org/wiki/Capability-based_security

Privilege-based escalation: https://en.wikipedia.org/wiki/Privilege_escalation

Principle of least privilege: https://en.wikipedia.org/wiki/Principle_of_least_privilege

MAC: Mandatory Access Control: https://en.wikipedia.org/wiki/Mandatory_access_control

On my system the root account is primarily for upgrades, but also storage administration! ZFS snapshots protects me against silly mistakes like strange permutations of `rm -rf ~/` in day to day operations. Not having root all the time protects me against `zfs destroy -r nagato/data/home/drbawb` which will nuke my home folder, 144 frequent snapshots (15 minute intervals per 36 hours), 14 daily snapshots, 4 weekly snapshots, and 3 monthly snapshots. That would suck. A lot. (I have a file called "RIP", where a drive image used to be mounted, because I got a little too over-zealous with the recursive option on some ZFS commands on a file that had `copies=1`. _RAID is not a backup, snapshots are not a backup, etc._)

This also means that theoretically ransomware (running without root) could encrypt my home directory, but apart from doubling the number of blocks used on disk it would have no real impact on my data. (If someone writes a virus that can encrypt the blocks inside a ZFS partition, without mangling ZFS data structures beyond repair, then I'll be more impressed than angry. Not even the ZFS devs can rewrite block pointers on a running filesystem.[1])

That being said ZFS has an awesome feature called delegation which lets you run a subset of commands without root permissions. I use it sparingly, mostly to allow unprivileged backups. (Each host gets a login on my backup server, and can only create/destroy datasets that are children of a host-specific dataset. So `nagato` can `zfs destroy -r backup/hosts/nagato` but not `zfs destroy -r backup/hosts` or `zfs destroy -r backup/hosts/someone-else`.)

[1]: https://www.youtube.com/watch?v=G2vIdPmsnTI#t=44m53s

Doesn't Qubes require like 32GB of RAM just to run?

I would love to use it, but most of the use cases I would like to try it for are much more in the realm of SBCs with 2-8GB of RAM for running services locally. It would be great to have that extra security, but the cost is really really high.

The even better than "best" practice is to not allow passwords for any login. Keys really aren't that hard.

> The best practice is not to allow passwords for root login.

My sshd is configured to not allow passwords logins at all: it's U2F/Yubikey only.

> Did you remove all of these?

So if you can't protect versus all the threats, you may as well not do anything?

What really matters is not whether you have sudo (or su, pkexec, etc.) installed, but rather that you never, ever escalate privileges from a less trustworthy user to a more privileged one, since at a conceptual level this combines the low trustworthiness with the high privileged-ness.

Instead, when you want to elevate privileges, you should do so by using a mechanism that takes the control of the machine away from less trustworthy user - such as a Secure Attention Key or similar mechanism.

If you want to grant particular systemctl start/stops to normal users, that can be done with policykit,

> Like, cat is on this list. And it's like, "you could `sudo cat` a file!" … well … yes?

The `sudo` tag means, if you're naively messing with /etc/sudoers, that allowing passwordless "command" with sudo might be a bad idea.

I still don't get the issue, that's going to be true for any program you run, unless it explicitly check if it's running using sudo. That however assumes that the program should never run with elevated privileges, which may be equally wrong.

Unless a program is designed for a very specific task and should always run as a given user, I'd argue that having it check privileges is both surprising and wrong. It's not the job of the individual programs to check permissions.

Edit: I see what you're saying. Having mail being a program that a user is allowed to run with sudo, it basically the equivalent for giving them a sudo access to a shell, because mail can spawn a shell, but with the same privileges as the mail command had.

The lesson here is just don't rely on sudo to give restricted permissions. I have been a Linux admin for 6 years and never had to do this, and pretty much every use case I've heard of has easily solved with a better method. If you need to give people access to certain files, make a group. If you need them to have certain capabilities of another user, let them switch to that user but not run privileged commands.

If user can run _only_ mail he won't be able to normally run sh. Of course you need to play a bit with permisions.

One of the listed binaries is `cat` and that `sudo cat file` is problematic because "it may be used to do privileged reads or disclose files outside a restricted file system."

Like, duh, that is what `cat` does. It's not the problem, it's the `sudo` is the problem. WAI?

In a previous role we had some access to production web servers but definitely not root access. Except for sudo access to vim which was widely abused as a way of getting a root shell when necessary. Fun times.

If it can perform arbitrary file writes (or even reads) then sure, I'm not at all surprised. A program with root access to the filesystem should be assumed to be a latent portal to arbitrary root execution, unless very thoroughly proven otherwise

There's a reason setuid is considered such a dangerous bit, and why "get root via this secure-looking setuid program" is a common exercise in computer security courses. Gotta look out for path traversals, TOCTOU, untrusted environment variables etc.

Part of the logical problem is the clash of security models. The program may well have been written to guard against untrusted input, but considers that to only be input files, not the commands the user gives. On the basis that "well if the user wants to hurt themselves by writing to /etc/shadow then it's their choice". But the situation in practice is a confused deputy problem, where the sysadmin wants the user to be restricted (despite the process not being restricted) but the program doesn't "know"

....except it isn't if you set up the git user with authorized_keys (user public key), and set the login shell for the system git user to nologin.

Congratulations. Git without bash. Unless there's another escape I'm not aware of.

You can directly map most of the tags into a libc function clall combination, like the "Command" tag is just programs that run user input into a system() call. Even for programs where this is their primary function. It has nothing to do with "bypassing".

The author is making a security theater out of nothing for posing.

> Best thing I found was to ptrace the child, and inject seccomp policies after startup

huh, apparently according to sudo manual that is exactly what sudo NOEXEC does

You're both half right. The trick is to use LD_PRELOAD to inject a SECCOMP filter. Then you can block execve(). See https://justine.lol/pledge/ and https://github.com/jart/cosmopolitan/blob/master/tool/build/...

I think it's more like "what you can use in your toolbox for effectively exploiting some privilege escalation vulnerability".

SUID is very explicit a tool only to be used for a very few niche use cases with very carefully crafted binaries. Basically a learned sysadmin putting SUID on an arbitrary binary (like most in that list) is enough reason to fire them for gross negligence without any prior warnings even in countries with strong employee protection, it's _that_ big of a "wtf. did you non accidentally do". So you don't really need a list for that.

Similar as any small tooling binary (e.g. cat, base64, etc.) is _supposed_ to run under sudo, i.e. it's definitively not a case of "not written with that kind of security considerations in mind".

Also for sysadmins this list isn't that useful as there are any number of arbitrary additionally binaries which behave similar on most systems, i.e. the list is very incomplete (and there is no way around that).

Similar "being able to read/write a file with the permission the calling user has" is normally not something you care about, the caller is anyway allowed to do so.

Or being able to trick a program to work as a form of shell (limited to the users permission) also normally doesn't matter. The user just can spawn it explicitly.

Except if you build a toolbox you want to use after finding some (potentially limited) exploit (or if you want to consider what such an toolbox would likely use). Then is list is grate as it makes it easy to find a way to archive something (e.g. shell) with as little custom code (and potentially without it being obviously in monitoring tools).

> e.g. during CTF

ah, makes sense, that also explains the slightly amateur-hour nature of some of them like shelling out of vi or gdb. I read the thing about not being vulnerabilities per-se (and if it hadn't have said that I'd have been irritated), but I did not catch the context of "live of the land".