2 ms·
It's been a long time since I read the NaCL publications so I might be forgetting some things. But, let's say IE9 were to move plugins to their own low-integrit
by briansmith 16y ago
It's been a long time since I read the NaCL publications so I might be forgetting some things. But, let's say IE9 were to move plugins to their own low-integrity processes (instead of being in the tabs' low-integrity processes like now). Given a perfectly-functioning mandatory integrity control system, how much of the additional NaCL infrastructure really provides extra security? How much of it "just" provides an extra layer of defense against kernel bugs and/or security for pre-Vista/non-Windows systems?
In other words, is this extra infrastructure something that Microsoft would really find useful to implement in IE9? Or, is it just needed for operating systems that IE9 won't support anyway?
- tptacek 16y agoBecause WinAPI, no matter what MAC system it implements, isn't enforced at the basic-block level, and NaCL is. NaCL has a smaller auditable attack surface. No matter what WinAPI does, the entire memory map of an x86-64 process is exposed to IE, and the same system call gates are exposed, and the same set of inherited process attributes are there. I'm not saying one is more secure than the other (NaCL's model is more elegant but theoretically riskier, WinAPI's is better tested and more conservative).