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. As far as bugs go I don't think this isolation relates to memory safety, a type and memory safe runtime can guarantee that such domains run in isolation and this does work in .NET ( I have never seen created domains compromised even though they share memory and GC - I did hear of one bug rumour but that is it) . For security attack agree for native / binary apps and libs. For a runtime that compile it really depends on how much the runtime abstracts it .. in nearly all cases (C# , Java , Basic etc ) Fileio is simply passed to the kernel with a nice wrapper , that won't achieve much.. but it does not need to be like that.. eg it would be easy enough to have a version of mono that allows no file access at all once you go into security mode.. pretty much what capsicum does but done in the runtime. For me for true isolations it's also important that a child cannot stop a parents thread - just like you can't with a process . 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. Capsicum is pretty simple in runs the client in a sandbox and is isolated.. >From memory there are 2 ways to go about this. 1) You setup all rights as normal before you go into capsicum mode , after which you lose them ( not sure how but prob the userid changes) .. Most C/C++ apps that become capsicum enabled do it this way , as its easy but really its not that secure . To be secure it would need to be done by a loader or runtime. 2) The correct way in capsicum is for the app to become "client server ".. eg the client is isolated and talks to the server via a capability and passes in capabilities it has . This server is really a small part of the app that access file etc , other servers can be capsicum "angels" including power boxes . In case 2 there is full isolation since they are in different processes. In does work but is a bit hacky and requires a significant change to the app.. More detailed here https://www.usenix.org/legacy/event/sec10/tech/full_papers/Watson.pdf --- 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. Yes , This is pretty much what capcicum does. Ben
<<attachment: winmail.dat>>
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
