[alufers]

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

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.

[mike_hearn]

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/

[mcdonje]

>Maybe I should write up a blog post on this stuff.

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

[mistrial9]

security so advanced that an individual software author cannot write a small MacOSX app, add an About box and cool icon, and distribute it themselves, as they choose?

[mike_hearn]

Assuming by "as they choose" you mean without buying a Developer ID then yes, they can do these things. In fact if you don't supply signing certificates Conveyor will self-sign your app and produce an HTML download page with instructions telling the user how to bypass GateKeeper. It'll also generate a `curl | bash` one liner to install it from the terminal. Obviously, this isn't meant for consumer software. Really you shouldn't bypass GateKeeper even if you're a pro level developer, although of course in reality we all do it.

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.

[mistrial9]

this is great to hear, thank you for posting a current overview

[NavinF]

Why troll? Nothing stops you from distributing a .app from your website

[mistrial9]

`$xattr -d com.apple.quarantine /path/to/file`

[mormegil]

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.

[jacquesm]

It does guard against someone installing a keylogger or network trick. I wonder how Samy's USB stick would fare in such an environment.

[ElectricalUnion]

If you're really paranoid, Qubes has a "USB qubes" vm to handle untrusted USB devices. Then you only need to trust that the attacker can't tamper with PS/2.

[westurner]

> 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

[kefyras]

>in suid binaries; like ping

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

[westurner]

"How can I identify if a binary file is set-user-ID?" https://unix.stackexchange.com/questions/192588/how-can-i-id...

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

[drbawb]

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

[sigotirandolas]

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.

[TacticalCoder]

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.