BK> Jonathan you mentioned the cost of unsafe as a tax on the user but there are BK> many apps where the introduction of a 3rd party lib/dll is a significant problem BK> possibly as significant as memory / type safety . Look at unsafe language BK> browsers that work well but grow unstable with add ins.
JS> Sure, but the main source of that instability is the lack of safety and isolation of the add-in. @Shap - I've been silently with you on on this entire fork of the discussion regarding importance of modular compilation, late binding (dll-ish), and matters of implementation selection in the large.. I want to value-add that the above statement reaches far-beyond type-safety and into the isolation and containment provided by operating system kernels. I say this because, despite many promises, we've yet to see a fully software-based isolation model that's worked out well in practice. I agree that type-safety (really memory safety) can close a huge surface area for bugs and security-attack-vectors into processes. However, IMO the lack of sufficient isolation boundaries and abstractions within operating system kernels are an equal or bigger issue than those within the processes and runtimes themselves. IMO the big missing link at the operating system level is to stop requiring "administrator configuration" to provide sub-component isolation... (more like Plan9/VSTa) Independent of the set of mechanisms used (capabilities, domain-hierarchy, virtualization), any application should be able to create an efficient containment sandbox --- which is **indistinguishable*** from a non-sandboxed environment to the contained component. This would stop holes in the runtimes and end-software from resulting in gaping-holes in system security. ----- Android is arguably the "most isolated" popular mainstream operating system, and they are providing their isolation not through purpose-built mechanisms, but by re-purposing the UNIX user-id protections to provide cross-app protection domains. This means apps are segregated from each other, but they are not free to create their own containment domains. I should become more educated about Capsicrum and the new-ish MacOS/iOS application isolation. As capability systems, I don't think they are capable of arbitrary end-application sub-containment -- though if I'm wrong about this I would love to be corrected. --- Overall, I just wanted to add that in practical security, IMO the lowest hanging fruit with the biggest gains is in providing more useful kernel-enforced non-privileged sandbox/container creation.... Then at least we will have a better tool to isolate the bugs we know may always be present within a single process boundary.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
