5 ms·

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 a

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.

drbawb 3y ago
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 https://www.youtube.com/watch?v=G2vIdPmsnTI#t=44m53s
mormegil 3y ago
Yeah, that's the classic https://xkcd.com/1200/ 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 3y ago
  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 3y ago
    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.
mike_hearn 3y ago
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/ https://hydraulic.dev/
- mistrial9 3y ago
  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?
  - NavinF 3y ago
    Why troll? Nothing stops you from distributing a .app from your website
    - mistrial9 3y ago
      `$xattr -d com.apple.quarantine /path/to/file`
  - 3y ago
TacticalCoder 3y ago
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.
sigotirandolas 3y ago
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.
westurner 3y ago
> 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 https://en.wikipedia.org/wiki/Superuser Capability-based security: https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security Privilege-based escalation: https://en.wikipedia.org/wiki/Privilege_escalation https://en.wikipedia.org/wiki/Privilege_escalation Principle of least privilege: https://en.wikipedia.org/wiki/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 https://en.wikipedia.org/wiki/Mandatory_access_control
- kefyras 3y ago
  >in suid binaries; like ping ping hasn't required suid in ages, there's net.ipv4.ping_group_range and CAP_NET_RAW.
  - westurner 3y ago
    "How can I identify if a binary file is set-user-ID?" https://unix.stackexchange.com/questions/192588/how-can-i-identify-if-a-binary-file-is-set-user-id/192590#192590 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 3y ago

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 https://www.youtube.com/watch?v=G2vIdPmsnTI#t=44m53s

mormegil 3y ago

Yeah, that's the classic https://xkcd.com/1200/ 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 3y ago
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 3y ago
  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.

mike_hearn 3y ago

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/ https://hydraulic.dev/

mistrial9 3y ago
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?
- NavinF 3y ago
  Why troll? Nothing stops you from distributing a .app from your website
  - mistrial9 3y ago
    `$xattr -d com.apple.quarantine /path/to/file`
- 3y ago

TacticalCoder 3y ago

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.

sigotirandolas 3y ago

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.

westurner 3y ago

> 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 https://en.wikipedia.org/wiki/Superuser Capability-based security: https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security Privilege-based escalation: https://en.wikipedia.org/wiki/Privilege_escalation https://en.wikipedia.org/wiki/Privilege_escalation Principle of least privilege: https://en.wikipedia.org/wiki/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 https://en.wikipedia.org/wiki/Mandatory_access_control

kefyras 3y ago
>in suid binaries; like ping ping hasn't required suid in ages, there's net.ipv4.ping_group_range and CAP_NET_RAW.
- westurner 3y ago
  "How can I identify if a binary file is set-user-ID?" https://unix.stackexchange.com/questions/192588/how-can-i-identify-if-a-binary-file-is-set-user-id/192590#192590 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)"