[Cryptography] Open Source Sandboxes to Enforce Security on Proprietary Code?

Tom Ritter tom at ritter.vg
Fri Aug 15 12:05:47 EDT 2014


AppArmor, SELinux.

The Chromium sandbox is open source, pretty sure NaCL is as well.
Mozilla is sandboxing the proprietary DRM blob inside Firefox, I
assume the sandboxing mechanisms are open source.

Building an open source app like Sandboxie using the Chromium sandbox
would be awesome.

-tom

On 15 August 2014 08:42, Kent Borg <kentborg at borg.org> wrote:
> Designing in end-to-end encryption is a good idea, but just because there is
> a claim that some product employs end-to-end encryption, why should any
> customer believe it?
>
> With open source programs there is a go-check-for-yourself response that,
> though it might not be practical, does pose a risk of discovery to those who
> might want to try to quietly inject a backdoor.
>
> But that doesn't do any good in assuring that a proprietary product is in
> anyway secure.
>
> Is there any work going on to build an open/closed hybrid, where a the
> closed source portion of the code is in a restricted sandbox that can't talk
> to the outside world, except through limited facilities provided by the open
> source portion, a part that is susceptible to go-check-for-yourself
> auditing?
>
> One doesn't have to worry as much about what product Foo is doing if we
> encrypt all its communication with a key that Foo doesn't know. Sure, Foo
> might implement a covert channel, but if we don't let it talk to untrusted
> endpoints, so what? Don't think of it as a covert channel, think of it as a
> proprietary feature that makes Foo's voice quality better than the
> competition's.
>
> Individual products might release portions of their source code to try to
> demonstrate how wholesome they are, but some standardization would be
> better.
>
> Recent Linux kernels have seccomp filters that can restrict and filter
> system calls, and that sounds useful, but is rather incomplete. The open
> source portions of Android made an attempt at implementing permission lists
> on app sandboxes, but it is full of holes.
>
> Are their other Usual Suspects are in this space?
>
> -kb, the Kent who has been musing over a product idea and but who is
> wondering how it could possibly be considered trustworthy.
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography


More information about the cryptography mailing list