Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

On Unix-esque systems, Mozilla Firefox stores a users' preferences, web history and stored passwords in a set of files that are readible and writeable by that particular user.

This makes sense: when the user bob is running Firefox, these files need to be readable by bob in order for Firefox to access them. However, this also means that any malicious application Bob accidently runs has access to this rather personal information as well.

So why wouldn't browsers like Firefox create a new user, with a random password, called something like firefox-bob, which would be the only user able to access these files?

Subsequently, the main firefox executable could be owned by firefox-bob, executable by bob, and have its setuid bit turned on.

It wouldn't surprise me if a similar system would also be possible under (recent versions of) Windows.

Of course such an approach would not be resistant against malware gaining root permissions or exploits within the browser itself. Still, I think utilising file permissions like this could significantly enhance the security of stored passwords or other private data.

Would this be a good idea? Or am I missing something? Are there practical issues with this approach?

share|improve this question
up vote 7 down vote accepted

This idea is in no way specific to web browsers. You could make the same argument that every application the user runs deserves to have its own segregated user ID under which to run.

Yes, some measure of security would arguably be gained by doing this because (for example) the malicious music player running in the same desktop session couldn't access the web browser's stored passwords. But I think you'd quickly find that the scheme as presented is impractical. The user wouldn't be able to access that file they downloaded with the web browser from their email software in order to attach it to an email, or for that matter from the file manager in order to delete it.

That's besides the fact that each system user now requires N users in /etc/passwd where N is the number of different applications they run. Not only does the system not provide any way of managing those accounts and switching between them, but it's just plain messy.

Your idea is a fairly significant departure from the UNIX security model but it has merit, and with the right kind of help from the operating system it can be done cleanly. Android works more or less exactly like this..

share|improve this answer

What you're thinking of is mandatory access control enforced on applications. This is still developing in the consumer OS space, but here are some examples of this thinking:

Windows does have a context based system of Mandatory Integrity Control, it doesn't differentiate access between applications of the same class.

One of my favorite context ideas is preventing even root from reading /etc/shadow, yet still allowing verification and changing of passwords. Here's the SELinux guide to that.

share|improve this answer
"One of my favorite context ideas is preventing even root from reading /etc/shadow," root can still change its own password, I believe. – curiousguy Sep 14 '12 at 1:58

However, this also means that any malicious application Bob accidently runs has access to this rather personal information as well.

Yes, and the most obvious flaw of your Firefox SUID approach is that "any malicious application Bob accidently runs" can send events to the X server to use the GUI of Firefox to read the passwords.

Messy, but doable.

OTOH, I feel that a normal Unix user should have the right to create many "subusers", different UID he would have total control over (including su, chpass and a secure version of rmuser). The sub-UID could have an obvious arithmetic relation with the controlling UID. I have always wished something like that.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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