Comment by someplaceguy | Hacker News Reader

Comment by someplaceguy | Hacker News Reader

Parent Full thread

> One way to do it would be for the program to manage it.

Really? So a program can access (and modify!) the state of all of its users?

Do you realize how easy it would be to trick my Firefox instance into reading (and even modifying) the state of another user, and even running other code on behalf of another user, given that it would have privileges to do so?

If I understand correctly your proposal, you basically just converted almost every single application bug into a privilege escalation bug.

Not to mention that how do you even define what the same "app" is?

Is Firefox 28 the same app as Firefox 45? And if so, can a user install his own Firefox (like you currently can on NixOS and even other OSes)?

Also, how would you backup all of your own per-user state, given that every app can decide to manage it differently (i.e. storing it in different files and/or directories inside their own per-app directory, or perhaps even in a single per-app database which you wouldn't have access to).

Look, I'm not trying to grill you, I just think you haven't thought this through (but again, I'm happy to be proven wrong).

> This is unrealistic. On the want majority of computers an app will only be run by 1 user. Focusing on handling multiple users is a more special case and is a distraction from the point I'm trying to make.

What does this even mean? We're talking about user-specific state. So there's different state for each user, which means there are multiple users, by definition!

So how is focusing on multiple users a distraction? It's the whole point...

As I mentioned, on NixOS, the system-wide mutable state is already stored on /var/lib/<app>, which is what you are (redundantly) proposing. So we're just arguing about how to handle user-specific state, nothing else.

>Really? So a program can access (and modify!) the state of all of its users?

I never said that. The same binary can be run by multiple users and the user running it affects what files it can read and write.

>Not to mention that how do you even define what the same "app" is?

The user has an idea on what the same app is. Unfortunately Nix does not properly understand this concept.

>Also, how would you backup all of your own per-user state, given that every app can decide to manage it differently

You could back up the entire state visible to the user.

>What does this even mean?

Having a single set of state for each program would be good enough for most users.

>As I mentioned, on NixOS, the system-wide mutable state is already stored on /var/lib/<app>, which is what you are (redundantly) proposing.

That is one place. Some programs don't use it. It's not a centralized place of state for every program.

> The same binary can be run by multiple users and the user running it affects what files it can read and write.

What you're proposing is not even possible with standard Unix permissions (without leaving a huge security hole). You're suggesting that each program can create the state for each user inside the program's directory but somehow cannot read or modify the state for other users.

This suggests the program runs with each user's privileges and therefore these directories would require the sticky bit for state creation (like /tmp does) but this would not prevent a user from roguely creating the state for another user (this is why files in /tmp should be created with random names, they should not be predictable).

Or maybe you're suggesting that all apps should run with setuid privileges (so that they can create the state for each user, but users themselves couldn't) but we already know that would be absolutely terrible for security.

So something like AppArmor (which AFAIK has security flaws) or even SELinux would be required to implement this scheme, I believe, if it's possible at all.

SELinux, AppArmor and other jail-like mechanisms can be a huge burden to manage, especially since most apps would require a substantial number of exceptions to a default security policy (think GUI apps, or apps that require access to a user's files, for example)...

Since most apps do require read/write access to a user's files, or permission to show things on a screen, I'm not sure if you're gaining much security with your scheme. There would be almost infinite ways for an app to exfiltrate or modify a user's files or trick the user into doing things on behalf of the app, I think (like running other apps...).

And if you're implementing a restrictive security policy with something like SELinux or even some kind of container/jail, you might as well do the same but without having to change each and every app to use the weird per-app directory containing the state of all users. This would save you a huge amount of work and potential security vulnerabilities, since private home directories are already secure by default (in terms of protecting a user from other users) and restricting an app not to access the state of other apps could be equally done when using home directories.

> The user has an idea on what the same app is. Unfortunately Nix does not properly understand this concept.

So a user can decide what "Firefox" is? Then what prevents a user from installing a rogue Firefox that exfiltrates the other users' state, in your scheme?

> That is one place. Some programs don't use it. It's not a centralized place of state for every program.

It is for programs that run system-wide and they should be using it.

Which system-wide programs are not using /var/lib for their mutable state?

It's not like they have many other places to save their state... I mean, there is /var/cache but that's for state that can be removed without data loss.

Reply on news.ycombinator.com