[langsec-discuss] Langsec and Java Object Serialization
munin at mimisbrunnr.net
Sat Jan 9 18:06:39 UTC 2016
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.sargent at gmail.com> wrote:
> On Mon, Nov 9, 2015 at 7:37 PM, Andrew Ruef <munin at mimisbrunnr.net <mailto:munin at mimisbrunnr.net>> wrote:
> I liked your writeup!
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the langsec-discuss