153950 - chroot and spawn execution

Status: NEW

(Core :: Security, enhancement)

Description

[Brian Hunt]

It would be wonderful if execution of **** on the net or attachments was done in
a chroot (or jail, for y'all BSD folk), for security. Spawning a process as a
'nobody' user would be very beneficial for security as well.

For the millions of people who don't care about security, I think that these
provisions will be very useful in the preservation of their machine integrity
over long periods of web surfing and numerous malicious email attachments. In
particular, for public access machines and embedded thin clients, this is a huge
bonus for the Unixy people.

Cheers

Comment 1

[Matthew Cline]

Looks good; confirming.

Comment 2

[Mitchell Stoltz (not reading bugmail)]

There's no Windows equivalent, is there?

Comment 3

[Matthew Cline]

I'm fairly certain there's no Windows equivalent; this is a UNIX only enhancement.

Comment 4

[Brian Hunt]

With a bit of speculating, a preliminary gloss:

Windows NT and derivatives should have ACL support. Therein file permissions can
be appropriately set to protect the system files (barring arbitrary priviledge
elevated code exceution). The objective on Windows would be, given that OS's
restraints, to execute code as a user with no write permissions.  Given the
lucid nature of Windows executables, this may break things in arbitrary ways,
but I am sure it can be done with reasonable tradeoff.

The chroot protections are not employed in the same capacity as on Unix; the
file system on Windows is more absolute. Neither is infalliable (ie. mount in
chroot is still absolute mounting), but certainly the protections of chroot seem
more systematically employed for visible holistic priviledge separation. On
Windows the priviledge separation is through employment of an unpriviledged
user; on Unix it is both the use of an unpriviledged user as well as the file
system separation of chroot.

Windows has greater permission breadth with full ACL's, but I would have to
speculate beyond reason as to the tangible benefit of using ACL's in this context.

So for the *nix's
 - Execute as unpriviledged user/group
 - Execute in chroot/jail
And for Windows
 - Execute as unpriviledged user/ACL

Comment 5

[Peter Asemann]

I'd suggest do split the browser in several components like qmail does.
A compontent which has network access. A compontent put into a chroot cage
(avoiding a break-out by using capabilities on Linux sytems that have
capabilities enabled)/jail to perform file system operations like
reading/writing cache files which the user does not want to be bothered with. A
compontent which has file system access to the whole filesystem. And an
unprivileged browser component.

The browser component makes use of the network component to access the network.
In case the browser component behaves strange, dhte network compontent could
raise an alert. The browser component would use the chroot component to
read/write exactly specified cache files. In case the browser wants to
upload/save files, the browser component has to ask the file system access
component to do so. So no evil script can secretly do anything to the
file-system. The file system access component then pops up a file system dialog
so the user is informed whenever anything is going to be done to the file system
outside the cache directories.

This way the user would be quite effectively protected against most evil I can
think of.

Comment 6

[timeless]

windows has runas and capabilities ...

[e-mail]: i'd be interested in seeing a patch, can i get it by 2010?

Comment 7

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Ideally, any files accessed in any way should either be 1) "owned" by firefox/mozilla/whatever (preferably literally . . . is there a bug requesting that Firefox et al. run as their own users?) or 2) selected by the user via a standard window-manager file-picker.  This is what Bitfrost enforces for all network-facing programs.  Is this practical?  Short of the occasional one-time thing, such as looking for IE/Firefox files the first time you run it, I can't think of a time when Firefox at least needs files in any other fashion.  I guess Java breaks this, but is that desirable anyway?

The next step would be to arrange a chroot/jail that interfered with neither (1) nor (2).  The obvious way to do this is abstracting all file access through a very simple but non-chrooted daemon running alongside Firefox, which would allow access to files outside the jail if they fulfilled one of the two conditions (or possibly other similarly narrow, prespecified conditions).  I expect the daemon would have to create the file-picker itself to deal with (2).

Clearly, this would sharply limit the damage any malware could cause.  Privilege escalation exploits would be more or less the only way to install anything that would outlast the session.  Are there any issues with this general idea?  Do Mozilla programs need broader file access, would it be difficult to abstract file access like this, would there be practical issues arranging the operation of the daemon (e.g. convincing the window system that they should be treated as one app for the purposes of focus-stealing and so on)?

Sadly, I'm more of a Web-developer type and can't realistically help out with any more details here, but it would be great if this could be worked out somehow at some point (FF4? 5?).  *Especially* if it could be gotten working reliably with Windows.  Then Firefox could justifiably call itself far more secure than any other browser.

Comment 8

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

I believe this should be marked parity-ie.  IE7 on Vista with UAC effectively implements chroot, although of course not in the traditional Unix fashion:

"The idea behind Protected Mode IE is that even if an attacker somehow defeated every defense mechanism and gained control of the IE process and got it to run some arbitrary code, that code would be severely limited in what it could do. Almost all of the file system and registry would be off-limits to it for writing, reducing the ability of an exploit to modify the system or harm user files. The code wouldn't have enough privileges to install software, put files in the user's Startup folder, hijack browser settings, or other nastiness."
http://blogs.msdn.com/ie/archive/2006/02/09/528963.aspx

This makes IE the only browser I know of to limit itself below usual process privileges.