Typically, each physical user on a system has an ID, and a running process is run as the user who starts it. This means the process is able to access all of the user's files, even those that not intended for this specific program. For example, if you start running Firefox then it has access to Chrome config files, and vice versa. But as you can see this is irrational because any browser works correctly without access to another's config files.

This is also dangerous if you consider one malicious program a user starts is enough to stealthily modify all of the user's files, plus send emails to other people as the user, access web accounts if the user stores a cookie, and many other possible undesirable behaviors. The root cause is that the process is running as the user, not as itself.

The problem has been partially remedied in commodity Linux systems by specifying UID and GID when starting a process. While this is true for many system daemons, it is not the typical case for client softwares. Many utilities such as browers, FTP clients, text editors are run as the user but not their own UID.

The OS which seeks an OS-level solution is Android, in which every app has its own ID and accesses user's data through permissions. It adds some complexity but prevents a lot of attack possibilities. If this is seen as good practice, then why isn't this feature ported to desktop Linux (Or has it)? With wider deployment of systemd, users are now having much better control of the processes they run and there shouldn't be technical difficulties in implementing such a feature.

  • 2
    Is there a question you'd like to be answered, or is it intended just to provoke discussion? – techraf Dec 14 '16 at 8:10
  • @techraf Is it good? If it's good, why isn't it applied to desktop Linux? Isn't it clear? – Cyker Dec 14 '16 at 8:19
  • 3
    Because I flagged the question to be closed? Sounds like a threat ;-) Luckily I flagged from the StackExchange app on Android. – techraf Dec 14 '16 at 8:25
  • 1
    It's not the problem of what font you use, the problem is that this question is unanswerable. All answers are equal. No, it's terrible practice, because Android employs it and is full of malware. Yes, it's great practice, because... No, it's not... Yes... And StackExchange communities are clear: they don't want such questions. It's not a site for discussions. – techraf Dec 14 '16 at 9:19
  • 1
    Most mobile platforms restrict access to data from apps. This creates a crazy situation where apps can't share data unless the OS vendor allows it. Any desktop developer has the ability to restrict access to application data or not depending on the need. There isn't a single answer to this issue. – Julian Knight Dec 14 '16 at 9:31

The question reverses the problem. Subsystem isolation exists for a long time in server OS through specific UIDs. You can even go one step further with virtual machines or jails in BSD systems.

For the client programs part, the desktop OS way is to split the program in two parts, an human interface that runs under the used id, and a daemon (or service in Windows world) that can run under its own id (think of databases like PostgreSQL for example).

So the security is in the hand of the system administrator who can choose a security pattern adapted to the sensitivity of the appliation/data.

But in Android, you have no access to an administrative account, so the end user cannot configure any security pattern. So the solution was to declare an user id by application vendor (note by vendor not by application!) in order to limit the damages caused by one application to applications of the same developper.

In the opposite, until the most recent Android versions, the end user could not choose to limit what an application could access: if the developper choosed to ask access to the contact directory, the user could not do anything against it except not installing the application.

So my answer is that one user id per application has no mean to be added to normal OSs because it is already present for a long time (provided devs make use of it). But maybe Android system will add features to allow the end user to control more finely what applications are allowed to do

| improve this answer | |
  • 1
    Even with a client-server architecture, the following scenario can happen: The server, running as an unprevileged user, listens on a local port. The client, running as the human user, reads the browser's cookie, encrypts and sends it to the server. The server relays the cookie to an Internet host, where it is decrypted. Now someone is able to log into your bank as you. Hooray! – Cyker Dec 14 '16 at 11:01
  • 1
    @Cyker Whatever the OS, if you have let a malware in anything can happen. How could having a user id per app protect you from keyloggers and mouse spies? – Serge Ballesta Dec 14 '16 at 12:23
  • 1
    If you configure your system not to send keycodes to processes running under UID nokbd, and do run dubious programs with UID nokbd, then they don't receive keycodes. It's possible that it has an accomplice, but then the question reduces to that program with the same logic. – Cyker Dec 14 '16 at 12:40

Not the answer you're looking for? Browse other questions tagged or ask your own question.