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

[coderman <coderman@xxxxxxxxx>]

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.

we claim #2 is solved, yet evilgrade has hundreds of vectors.  again,
we should be doing both.



> 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.

looking at one aspect, reproducible builds or package management, is a
narrow misleading perspective.  as mentioned before, a vulnerable
application built reproducibly and distributed securely is still
vulnerable.

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




> 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?

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.

and again, which reduces risk the most is very context dependent.
(and we should do both :)



> 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?

who reads gentoo patch sets?

again, risk is complicated. and we should fix both problems.
(complicated distribution patches, as well as dependence on binary
packages without independent validation (reproducible builds, etc))



> Sure, I can't get it to run anymore. Probably too many USE flags.
> It's a shame too little people care for maximizing the security of
> their computing stack. We need distributions that compile fully
> from source, and we need them to compile reproducible so that it
> is fine to distribute them also in binary form.

i agree with you 100% here!

(and i also hated my use flag magic, and overrides, and wondering what
in portage shifted under my feet such that builds which used to work,
no longer after updating some other component, etc.)



>> the most usable source based distribution still needs to be built, and
>> that is both time consuming and resource intensive, comparatively.
>
> Guix, please lead the way.
> Give us a new reproducible distro soon!

i like Guix; binary pre-builts for the impatient. source based
rebuilds for the conservative.



> I mean, let's stick to reality - the attacker loves simple and easy
> straightforward things.

it's not that simple, though many threats do take path of least
resistance. some times stealth is more important than easy. other
times zero-persistence (memory resident only) methods are desirable,
despite being more complicated.

as i've said before, risk is a complicated thing, and which threat
matters most to you is context dependent.  in industry jargon, "what's
you threat model?"

we need to solve for many.



> 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.



>> question everything!  (the sources, the default configurations, the
>> distribution, ...
>
> Which isn't a helpful way to put it.
> 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 :)



> It is still about Whonix + Qubes OS being a special target for attack
> and the question why one would make a TAO effort at such an exotic
> platform if it is much cheaper to put backdoors into debian binaries?

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.

a vulnerable throw-away App VM doesn't get to compromise devices in
other domains, nor persist across instances.

finally, this is an example - created for sake of demonstration. why
does TAO do what they do? they have offensive addition is my best
guess.
[ see https://docs.google.com/presentation/d/1Sv8IHkBtBEXjSW7WktEYg4EbAUHtVyXIZBrAGD3WR5Y/preview?sle=true#slide=id.p
]

could i have used a Gentoo hardened Tor user for the example? sure. my
apologies if my choice in this matter has annoyed you!



> Given that Whonix + Qubes OS still use debian binaries, which I am
> not sure of. Concerning the anonymization architecture Whonix + Qubes
> OS is certainly the most advanced thing I've ever seen.

Qubes OS is based on Centos, while Whonix is based on Debian. Whonix +
Qubes OS a chimera, and perhaps one day you'll have a usable Gentoo
Hardened App VM template for various other paranoid purposes, too.

best regards,
-- 
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