I liked these posts! The sandbox stuff in Java is ridiculous. It seems like there’s a parallel between the usability of the sandbox API and the usability of crypto APIs: there are primitives that exist to try and provide some kind of security guarantee but they’re so difficult to use that they are rarely used correctly.
Traditionally the “Turducken Security Model” is called “defense in depth” and is considered a “best practice” ;) It seems that this kind of sandbox and containment is overall a good idea because projects adapt them to their benefit: vsftpd, chrome, quark, etc, and others ignore them to their determent: firefox. It follows in a tradition that goes back to operating system design: the boundary between user mode and kernel mode. Traditionally this boundary becomes porous due to low level defects in the system call layer that allows for code execution, but absent those defects the design provides the protection that you want. Probably? “Sandbox” in this case just seems to be “a way to evaluate something with a reduced set of credentials” and “trust in the access control mechanism”. For example, Haskell LIO: http://www.scs.stanford.edu/~dm/home/papers/stefan:lio.pdf <http://www.scs.stanford.edu/~dm/home/papers/stefan:lio.pdf> https://hackage.haskell.org/package/lio <https://hackage.haskell.org/package/lio> which you can just use in your code to enforce security policies. So when you go to unmarshal some data or something, the function that does the evaluation drops to a low security label and then if crazy stuff happens during unmarshaling it can’t touch anything else. Of course, back to the original point: these kinds of compromises happen because someone looks at ObjectInputStream and thinks “that looks fine” and there’s nothing in Java at the type level that tells you “this is dangerous” so out comes the foot gun… > On Jan 6, 2016, at 12:42 AM, Will Sargent <will.sarg...@gmail.com> wrote: > > On Mon, Nov 9, 2015 at 7:37 PM, Andrew Ruef <mu...@mimisbrunnr.net > <mailto:mu...@mimisbrunnr.net>> wrote: > I liked your writeup! > > this seems to be a case of one party telling another party “hey take this > program from me and run it in the same security domain that you do, thanks.” > it’s “the same security domain” that’s the problem (along with the lack of > realization that this is what ObjectInputStream does). it’s also a problem > when the mechanism for enforcing the security domain, like the JVM or a > javascript interpreter, is busted. if the security boundary is good though, > then this isn’t a problem. when is the security boundary good though? maybe > seL4 is good enough, maybe quark. > > I poked more at this whole "security domain" thing: > > * > https://tersesystems.com/2015/12/22/an-easy-way-to-secure-java-applications/ > <https://tersesystems.com/2015/12/22/an-easy-way-to-secure-java-applications/> > * https://tersesystems.com/2015/12/29/sandbox-experiment/ > <https://tersesystems.com/2015/12/29/sandbox-experiment/> > > Although as far as I can tell, you should be running the JVM inside of > Docker, inside of a VM, inside of AppArmor and seccomp (whatever that is), > with a patched grsecurity kernel. And CoreOS is involved somehow. > > The temptation to call it the Turducken Security Model is strong. > > Will. > >
_______________________________________________ langsec-discuss mailing list langsec-discuss@mail.langsec.org https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
