[tor-relays] new relay package for Ubuntu 16.04+

[Chad MILLER]

* Green Dream <greendream848 at gmail.com> [2016-08-30 21:39:34 -0700]:
>chad> 1) anyone can create packages for others without review, 2) security 
>>is better
>
>These 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20160831/63c0e746/attachment.sig>