Re: [tor-talk] Qubes? debian? binary? reproducible? (was: EGOTISTICAL something)

[carlo von lynX <lynX@xxxxxxxxxxxxxxxxxxxxxx>]

grarpamp, thanks for making me look at
http://cryptome.org/2014/12/peck-roark-affidavit.pdf

I had dared to skip it, albeit it says a lot about the person
I am holding an exchange with.

On Sun, Dec 07, 2014 at 10:15:31AM -0800, coderman wrote:
> On 12/7/14, carlo von lynX <lynX@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> > I wasn't talking of (2) because that is a given which isn't questioned
> > anywhere. I was only talking of (1). I don't know why you bring (2) into
> > the discussion as if there was any problem with that. Unless you are
> > using Microsoft Windows, there is not.
> 
> see openwrt, for one common example.

People who let openwrt update itself without cryptographic
protection are irresponsible.

> > Legitimately so, still the attacker has a much harder time.
> > I don't understand why you reject plausible prioritization.
> > By throwing all problems into one big basket you defocus.
> 
> i am not rejecting prioritization,  nor trying to defocus with a big
> basket. what i am saying is that risk is a very context dependent,
> multi-faceted thing.

Which is a refined way of saying the same thing.

> which is the bigger risk? binary packages or vulnerable applications?
> it depends!
> (and we should do better on both fronts :)

Binary packages are the bigger risk. I have provided argumentation
for that and you have not challenged that effectively.

> > Yes, gentoo has been lax on that for many years.
> > Now it supports gpg-signed portage updates, so that problem is fixed.
> 
> not "fixed", but made more difficult. how well do all signers manage
> their keys? would they know if a signing key was stolen? how would you
> know?

If I am correctly informed debian has two large attack vectors:
Either you get friends with a package maintainer and get her to
upload unsafe binaries (and the attacker can choose such maintainers
based on evaluating all of her past email transactions etc - possibly
even blackmail them with information which was supposed to be private),
or they get access to the VPS machines doing the automatic compilation
of the binaries the maintainers did not upload, which is probably not
so hard and has the advantage that no-one within debian needs to be
in the know. Ultimately, if the PGP private keys reside on those VPS
servers, targeted attacks become feasible - right there in the process
of a routine apt-get upgrade.

Whereas with gentoo I would assume there is a limited number of
persons that certify the daily generated portage images. Even if
the attacker gets his hands on the private keys, he needs to
falsify clear-text scripts or patches, thus material that can be
easier detected and used as evidence against him compared to binaries,
then choose between getting those evident changes distributed by the
entire gentoo backend - maximizing the risk of getting caught - or
targeting specific persons, which means making false versions of
portage and knowing from which of hundreds of mirrors the targeted
person will try to https-rsync it from. The attacker thus has to be
close enough to the target to MITM all https-rsync operations, which
depends on the system being dumb enough to not do certificate pinning.

All in all the source distribution is a whole lot harder to attack
than the binary distribution and can even be improved by providing
system level certificate pinning like with libcertpatrol.

Other option to improve the safety of the procedure would be if there
was a mirror running on a .onion, .i2p or .gnu since those aren't as
easily MITMable.

> part of the benefit of reproducible builds is a consensus of digests
> from multiple parties. this is different assurance than a signed
> source package, which you build yourself.

Yes, reproducible builds would be a step into the future. Right
now source-code based systems are more secure, unless somebody in
here can really challenge the argumentations I laid out.

> > Every time a source code dares to contain a backdoor, there would
> > be a responsible you can grill. And since gentoo doesn't maintain the
> > source codes itself, a gentoo maintainer would have to hide it in the
> > additional patch files. Good luck with that!
> 
> you understand that the Debian openssl flaw was a patch against
> upstream, rather than a rogue binary, right?

I understand that sometimes such spectacular mistakes make it
even on a source code level, whereas we won't even find out about
unspectacular backdoors introduced on a mere binary code level.
And that is the easier route to take. So there is no way to figure
out how many "sleeper cells" are already in our linux DVDs.

> who reads gentoo patch sets?

I take random glimpses into patches and git pulls.
If everyone does, there is no guarantee that the costly investment
in introducing a source-code level vulnerability will pass undetected,
whereas a binary vulnerability is close to a safe bet.
Stays undetected until the day it is actually activated for something,
and even then it takes very competent folks to observe its actions
and figure out where things went wrong.

> > So let's please prioritize the threats. Using somebody else's binary
> > is a threat. Crosscompiling a linux from scratch for yourself is likely
> > to be safe because the attack vector is just too much effort to prepare.
> 
> i disagree that building from scratch is safe. it may be less risky
> than binary packages in some situations, but that is the most you can
> claim in broad strokes.

Yeah yeah. Keeping people from working out priorities and making
reasonable choices by throwing everything into a big basket of uncertainty.

> > We got to have priorities.
> > And we can use our brains to set them.
> 
> priority #1: fix what is broken.
> (unfortunately, it seems almost everything is broken :)

Big basket logic.

> what you don't mention here is IOMMU isolation between domains in a
> Qubes OS system. your Gentoo hardened, running one vulnerable app,
> leading to one vulnerable device, is a class break, as you could call
> it. full compromise.

Yes, I didn't mention that running a source-code based Qubes would be
better than running a Gentoo. Do I also have to mention 2+2 = 4 or
will you challenge me on anything I have not said?


-- 
	    http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk