Well, I can think of a "nobody" user with home in, say,/tmp/nobody, and flash is running with it's uid and cgroup'ed, so:
flash can read any libs or binaries (for these raw graphic ops, I presume) from fs as needed.
flash can't access sensitive data in/home/myuser.
flash can't write to/home/myuser/.mozilla/firefox/**/some_binary_file (that might get injected into process, run as "myuser").
it can write to it's own "home" and access network as it pleases, although it will die along with a browser tab (cgroup gets killed, and flash can't escape it via forks).
I don't know much about what files flash accesses on local fs, but it certainly doesn't need write access anywhere but $HOME on unixes (works fine w/o it as it is), and I doubt it ever accesses ~/.mozilla (or ~/.opera, ~/.chrome, whatever) directly - these are subject to a constant change and shouldn't be necessary for the plugin which has direct interface to a working browser (whatever one it is).
What am I missing here?
Ok, now that we're able to put flash code in a separate proc, my question is: can we cut it's privileges so another (monthly) "zero-day vulnerability" will finally become just a tale to scare little children? Strangely enough, with all the concern about flash security, article seem to miss that point.
Slashdot Mirror
I don't know much about what files flash accesses on local fs, but it certainly doesn't need write access anywhere but $HOME on unixes (works fine w/o it as it is), and I doubt it ever accesses ~/.mozilla (or ~/.opera, ~/.chrome, whatever) directly - these are subject to a constant change and shouldn't be necessary for the plugin which has direct interface to a working browser (whatever one it is). What am I missing here?
Ok, now that we're able to put flash code in a separate proc, my question is: can we cut it's privileges so another (monthly) "zero-day vulnerability" will finally become just a tale to scare little children?
Strangely enough, with all the concern about flash security, article seem to miss that point.