Linux, setrlimit, and Mozilla/Gecko renderer security

Discussion in 'all things UNIX' started by Gullible Jones, Jun 13, 2014.

Thread Status:
Not open for further replies.
  1. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    aka "fake seccomp."

    Firefox is famous right now for not having any official sandbox. But on Linux, what's to keep it from running something like

    Code:
    struct rlimit ffox_procs = { 0, 0 };
    setrlimit(RLIMIT_NPROC, ffox_procs);
    in each renderer thread, immediately after the thread is forked? One could probably do the same for file handles, since those shouldn't be needed once the rendering thread has loaded a page into memory... No? That wouldn't be anything on Chrome's sandbox, but if practical, it would certainly make attacks on the rendering engine a little harder. Especially blocking all file handle access.

    (Actually it wouldn't surprise me if Gecko already does stuff like this; and if not, I'm sure there's a very good reason. I'm just interested in seeing what the deal is with this.)
     
  2. Mrkvonic

    Mrkvonic Linux Systems Expert

    Joined:
    May 9, 2005
    Posts:
    8,698
    It would make attacks ... what attacks?
    Mrk
     
  3. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
  4. Mrkvonic

    Mrkvonic Linux Systems Expert

    Joined:
    May 9, 2005
    Posts:
    8,698
    That's not attacks. It's like saying you're vulnerable to Ebola and AIDS. And?
    How do these relate to your daily activites or your exposure to these unpatched threats in your immune system?
    Mrk
     
  5. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    So I posted something about this on Mozillazine 10 days ago, and still no reply... Looks like that was the wrong place? And Mozilla has no official discussion forums any more? Sigh.

    Perhaps I will see if I can patch Qupzilla to do this, or something dumb like that.

    Edit: if possible I'd also want to set RLIMIT_NOFILE to { 0, 0 }, since without file handles you can't do much in the way of persistent damage...
     
  6. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    Turns out Linux has a prlimit() library call that sets rlimits on a running process. So I cobbled up a C program to set NPROC and NOFILE limits on arbitrary PIDs.

    NOFILE was a bust. Any calls on filehandles, even already open ones, will fail disastrously with NOFILE zeroed, instantly crashing the target program.

    NPROC on the other hand sort of works, but some programs handle it much better than others.

    e.g. ROX Filer with NPROC zeroed will fail to execute programs, and give a popup message explaining that fork() failed, and perhaps you have too much stuff running. This is what *should* happen.

    Firefox on the other hand thinks it should be able to fork() indefinitely. When forking fails, it immediately tries again, and again, and again... quickly causing itself to hang. This can happen any time, and is also pretty much guaranteed if you render something Javascript-heavy (like GMail :( ) or have more than 3 tabs open.

    I'll see if there's anything to be done about that, but I am betting not...

    In any case though, without the NOFILE limit working this is not a very good sandbox at all.
     
  7. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    Bah, turns out that preventing fork() does not prevent exec* from working just fine... There's your answer. :(
     
  8. fblais

    fblais Registered Member

    Joined:
    Jul 31, 2008
    Posts:
    840
    Location:
    Québec, Canada
    What's your conclusion then?
    Better not use FF?
     
  9. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    No, my conclusion is "don't try to gimmick up a sandbox using a mechanism not designed for such." :)
     
Loading...
Thread Status:
Not open for further replies.