setrlimit() as a security measure on Linux. Sensible?

[Gullible Jones]

Something I realized about setrlimit(), which is invoked by the ulimit command:
- A process cannot fork at all if RLIMIT_NPROCS is { 0, 0 }
- A process cannot manipulate any file handles if RLIMIT_NOFILE is { 0, 0 }
- Once an rlimit is lowered by a limited user's process, it can never be raised again by that process or its children (per standard UNIX DAC).

This is not too useful with just CLI tools. But together these things might allow for a kind of budget internal sandbox on Linux, that might limit the scope of damage of certain exploits.

My thought is that, after each Firefox thread has been forked and before it has actually starts processing page content, it could call setrlimit() to throw out all process spawning and filesystem (including VFS) access privileges. An malicious party that gained control of that thread (e.g. with a Javascript exploit) would be limited to subsequent avenues of attack that did not rely on spawning new threads or processes, or on interacting with file handles.

Now the caveat...

I don't know anything about Firefox's design, other than that it's obviously multithreaded. I don't know if there's any place where setrlimit() calls could be put in safely and effectively. Actually, because I'm not a complete ego-monkey, I'm going to guess that there are very good reasons why this has not been implemented, that I just happen to be ignorant of...

Still, I'm interested in what people have to say about this. If it's feasible, could it conceivably wind up in the Linux version at some point, as a compile switch? If it's not, could someone explain what's wrong with the concept?

Thanks...

[DavidNoah]

is there any secure extension which can easily check our files.