I don't know if all of this applies to OSX, but I'll answer from Linux perspective. (some of these are in common, I'm sure) There are restrictions for your user that you can set up as root, but your user can't touch. For example firewall, process restrictions, security labels, etc.
What does it mean in practice: if you set up appropriate restrictions and run (for example) `curl http://...` and curl gets exploited via malformed response:
- it cannot write to system configuration
- it cannot write to user configuration
- it cannot spawn shell
- it cannot bind port to get remote commands
- even if it could, it cannot receive traffic, because it's configured as outbound-only
- while it can send data on the same connection, there's not much to send, because:
- it cannot read your browser saved items (password, history, etc.)
- it cannot read your ssh configuration / keys
...
So yes, superuser access is still important, because it can set up defences which only superuser can override. Not many systems use it so far, but the frameworks are available.
I think the biggest impact currently in this area is the Chrome sandbox, but this one can be actually user-activated.
If an attacker successfully compromises my workstation and can masquerade as me, and the most useful thing they can think of doing is to pivot and rewrite my SELinux rules as opposed to, grab my password database (or just keylog my banking sessions), then I will be a very happy man.
I think mobile actually leads the way in this area, with applications restricted in actions they can take, regardless of who they're running.
My point was - before they can read the password database (or even find that a password database exists), they need to break out of selinux enforced rules. It's not an end goal - it should be a prerequisite for any further data collection.
Key logging should not be possible in an exploited application either. Actually if you've got some healthy paranoia, you're maybe running QubesOS and your banking doesn't touch any other work environments.
Of course this is tricky in case of browsers. But that's also why I don't keep my password in the browser ;)
What does it mean in practice: if you set up appropriate restrictions and run (for example) `curl http://...` and curl gets exploited via malformed response:
- it cannot write to system configuration
- it cannot write to user configuration
- it cannot spawn shell
- it cannot bind port to get remote commands
- even if it could, it cannot receive traffic, because it's configured as outbound-only
- while it can send data on the same connection, there's not much to send, because:
- it cannot read your browser saved items (password, history, etc.)
- it cannot read your ssh configuration / keys
...
So yes, superuser access is still important, because it can set up defences which only superuser can override. Not many systems use it so far, but the frameworks are available.
I think the biggest impact currently in this area is the Chrome sandbox, but this one can be actually user-activated.