On my desktop (and probably 99% of people's desktops here) getting access to the user account is game over. The password manager? Runs as my user - one ptrace and the key can be extracted. Cookies for all my online services? Sitting right there in the home directory.

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

And don't get me wrong, I don't like this situation - I tried running some high-risk programs (browser, Libre Office) under flatpak to achieve at least some separation - but it breaks too many things.

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.

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 too used to be maximally skeptical about this stuff. I saw what Apple did with iOS and like so many others saw the writing on the wall. But it's been 15 years now and you can still distribute and run unsigned Mac software if you want to. Developer ID/notarization remains very different to app review. App sandboxing remains optional. You can still get root if you want, both the default de-privileged version and the full fat version (by disabling SIP).

In the end the wall writing existed only in our minds. Apple have never closed the macOS platform like with iOS, and honestly I see no sign they ever will.

Please do. And post it to HN. It could inspire some distro maintainers.

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.

* 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.

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

ping hasn't required suid in ages, there's net.ipv4.ping_group_range and CAP_NET_RAW.

    test -u "$(type -p ping)" && echo "the suid bit on ping is set"
    ls -l "$(type ping)"

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

"Never allow root SSH" together with the strong implication that it should be used in conjunction with sudo, has always had a very weak rationale behind it, since as soon as you actually ever make use of sudo to elevate your privileges, for an attacker there is almost no meaningful distinction between your user account and plain root.

Looking at the historic reality, the weak rationale more than evaporates completely. Due to various CVEs, sudo has, in retrospect, been a trojan horse for most of its existence that allowed privilege escalation from any user account regardless of its configuration. The period for which sudo has had these vulnerabilities overlaps rather well with the period for which it has been championed as "best practice" along with the tenuous justifications based on security by obscurity and to avoid "user mistakes."

In that light, your setup seems perfectly sane to me, however I don't believe sudo is relevant as a backdoor anymore in 2023 and the focus has most likely shifted to something else.

Edit: I'm curious because if you still allow su on the system there seems to be little to no reason to set PermitRootLogin in sshd_config regardless of auth mechanism (password, cert, token, etc.).

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)

I use Qubes OS for stuff like this. Way better security, no need to juggle tokens, dedicated lans and so on. Only real problem is no graphical acceleration in browser (Google Earth...)

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.

32 GB minimum, but 16 GB recommended.[0] I think that's backwards, so I'd say it's actually 16, not 32 required. But yes, that's more than a typical SBC will have. The Pi 4, for example, has a maximum configuration of 8 GB, but some have modded it to have 16 GB.[1]

[0]: https://www.qubes-os.org/doc/system-requirements/

[1]: https://www.techradar.com/news/a-raspberry-pi-4-with-16gb-it...

I see Memory: 6 GB RAM under Minimum

Allowing root login is fine. 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.

  $ cd /usr/bin
  $ for x in ./*; do [ -u "$x" ] && printf "$x\\n"; done
  ./at
  ./atq
  ./atrm
  ./chage
  ./chfn
  ./chsh
  ./crontab
  ./fusermount
  ./fusermount3
  ./gpasswd
  ./mount
  ./newgrp
  ./passwd
  ./pkexec
  ./sg
  ./staprun
  ./su
  ./sudo
  ./sudoedit
  ./umount
  ./vmware-user
  ./vmware-user-suid-wrapper
  $ cat /etc/redhat-release 
  Red Hat Enterprise Linux release 8.8 (Ootpa)

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

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.

  $ ls -l /usr/bin/passwd
  -rwsr-xr-x. 1 root root 33424 Apr  1  2022 /usr/bin/passwd

You would not be able to change your password without the functionality.

The former are fine since they don’t allow arbitrary commands/escalation, and the latter (IMO) you should not use because it’s impossible to use them safely as you can’t trust the environment (the display server, terminal emulator, shell, etc.) to do what you say if it is compromised.

In practice, some of them will have bugs (and the kernel also has privilege escalation bugs frequently) so I don’t consider the user/root separation a particularly strong security boundary. For me it’s more of an additional layer against not very sophisticated attacks.

OTOH, if people are expecting literally every program to open file handles / network sockets, then drop privileges to something else, that's a weird expectation.

I'm in the no sudo camp myself.

Yes, I hate sudo's unwieldiness too. The very first thing I do after installing one of those distros that default to no-root-login (Ubuntu, Mint, etc) is to give root a password.

The downside is that I allow "root SSH", contrarily to every single best practice out there.

Why can't you log in via SSH as a 'normal' user, and then "su -" to become root? I use that method, and it obviates both the use of sudo and the allowance of "root SSH".

https://man.openbsd.org/doas

These bypasses are useful if you want to get root access on a machine you are given some, but not all administrative rights, like a shell and a few sudo commands, for example to restart a service.