Roger Clarke wrote: > 'really tight sandboxing', is an absolute must Security isn't that simple.
Consider an operating system with each application in its own sandbox. Now let's say a linker library has a bug. We need to update that library in every single sandbox. In the "application shipped as a sandbox" model (phones, Docker) then you're relying on application authors to update their shipped applications, but they have little motivation to do so (they aren't going to see additional revenue, customers lack sufficient market information when purchasing the application to know how diligent the author is with security updates). In the non-sandboxed model an update from the operating system's manufacturer suffices to update all applications (OS authors have an expectation of future sales, and their performance at issuing security updates is widely reported). This shortcoming of sandboxes explains the attraction of alternative security mechanisms which seek to limit unauthorised access to the operating system (SELinux, etc). The issue there also becomes one of management: who is responsible for the authoring of the type enforcement rules (neither the application author nor the operating systems' manufacturer feels the cost should fall upon them)? Neither of these might give you the security you want. Sandboxes and type enforcement usually degenerate to protecting the operating system from misuse. That often doesn't do much to prevent manipulation of your data pr misuse of your systems resources. Sandboxed applications typically ask for far too much access to your data (just look at the Facebook app's landgrab over your phone's data) and type enforcement schemes often don't apply to your data at all. There's no magic bullet here, or this would be a solved problem with the one obviously right answer already deployed. -glen -- Glen Turner <http://www.gdt.id.au/~gdt/> _______________________________________________ Link mailing list [email protected] http://mailman.anu.edu.au/mailman/listinfo/link
