* Green Dream <greendream848@xxxxxxxxx> [2016-08-30 21:39:34 -0700]:
chad> 1) anyone can create packages for others without review, 2) securityis betterThese two concepts seem fundamentally at odds. Perhaps I have misunderstood you. How would unreviewed code be better for security?
Good question. It's better because it was beyond terrible before. "Security" means nothing without a lot of context, but maybe we can agree it means enforcement of some policy.
When you run a program in this packaging scheme, it is confined to a specific set of syscalls (seccomp), used in a specific few ways (apparmor), and through some mounting of filesystem images that don't even implement write() (squashfs) and bind mounts, it appears to itself to be the only program installed on an otherwise barebones linux machine with almost nothing writable execept a few data directories that it's informed of at run time. No matter what else is installed, it can't do much about it, and if it tries to get uppity, the kernel will likely slay it.
It gets access to previous versions of its data, so it could clobber that. The packages I have here request "network bind" and "network" permissions, so a bad program could create sockets. (Which is nothing to sniff at!)
It could also steal resources like CPU time or RAM.But it can never look in your ~/.gnupg/ dir or grab your scanner or wipe your yubikey or turn on your camera or whatever, as another program, rogue or compromised, could do. None of that even seems to exist.
This is a packaging system with dense policy built-in, and it's enforced so pretty much the only thing software can see is its own belly-button.
Reviewed code is great, but large swaths of code on our machines has had one or fewer very interested persons look at every line. And one line is all it takes to be catastrophic. Better to treat every program as guilty and untrustworthy. Design for untrustability instead of hoping for diligence.
Snap is not perfect, and it's not my baby, but I admire it. -- Chad Miller chad.org c2c3 0e6c a4ce d49e 79cf 06c61 a806 deac 3042 0066
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays