On Thu, Aug 13, 2015 at 11:23:19AM +0200, David Kalnischkies wrote:
> On Wed, Aug 12, 2015 at 11:12:05PM +0000, Anthony Towns wrote:
> > I'm not sure if the idea is PPAs can only be added to by DDs/DMs. [...]
> There is a session about Debian PPAs at 2015-08-21 17:00..18:00
> @ DebConf, so all the details there I presume, but as far as public
> information up to today goes (which I have seen) is that they are
> limited to DD/DM, on Debian infrastructure and signed by the usual
> archive signing key, so that trust in the archive-key isn't an issue
> here – the problem is just in "easily" adding PPAs to your sources which
> while currently bundled in this thread as well, I would like to avoid as
> a topic for now to focus on the archive-key part for external archives
> which aren't signed by Debian.

Yeah, that mostly sounds straightforward -- apt key is already fine,
uploads and new repos don't add much more risk than unstable already has,
everything in PPAs goes to a central server and can be tracked so it's
not easy to use PPAs to sneak things onto individual systems.

The downside is it limits things to DDs/DMs, so it doesn't make it much
easier to get totally new stuff available for Debian users, so that's
where extrepos come in.

> > To use an external repo, you need a deb822 sources.list file and a pubkey.
> > 
> > To get those, you contact extrepos.debian.net, and either do some sort
> > of search, or plug in a 6+ digit hex code. extrepos.debian.net spits
> > back a signed bundle of the repo's public key and a deb822 sources.list
> > (which includes a description of what the repo is meant to contain), both
> > named to match the 6+ digit hex code.
> That could work (see also below), you "just" need to figure out a way of
> registering an external repository at extrepos.debian.org now, which
> involves deciding who can register one and how to ensure that what
> I register is actually owned by me because…

I think my working assumption is "anyone" can register, and it's done
automatically. If you want to ensure the URL is owned by the register,
you could use a dummy DNS record ("please add
   extrepo-de684554ae0c3440.example.org CNAME extrepos.debian.net.
to your DNS").

> > > > Or did you mean that the DD signs the sources.list file directly? Well,
> > > > then my key isn't usable for that right now, but in exchange the DD
> > > > might have a slight problem in assuring the correctness of what he is
> > > > signing: I am the owner of example.org/debian. Trust me.
> > I'm not sure this is a problem -- if you're not the owner of
> > example.org/debian, then the files I download from there won't have your
> > signature. If they do have your signature, then it's just the question
> > of whether I trust your random repo, and I can't figure that out just
> > from knowing who you are.
> … I was thinking man-in-the-middle here. If I can register
> example.org/debian with a key of my choosing I can do really bad things,
> especially if example.org is the domain of a Debian mirror and I manage
> to trick people into adding this e.g. by claiming that this is a faster
> mirror…

I still don't think this is true?

Let's suppose you've found a mirror of a PPA that's intended for building
honeypots, so it has a version of sshd with a bad random number generator
and a couple of known exploits. It's signed by the Debian archive keyring.

Now I create an extrepo as follows:

  Type: deb deb-src
  URI: http://mirror.example.org/debian-ppas/honeypot/
  Suite: stable
  Section: main
  Description: security enhanced sshd
   This repo contains enhaned builds of sshd and some related
   utilities with vastly improved security options over the
   standard builds in Debian.
  Signing-Key:
   [archive signing key goes here]

How is that an advantage over just setting up my own extrepo with
dangerous packages and a misleading description?

If you put in a /different/ key and go to the trouble of intercepting
some users' traffic to example.org, things look slightly different:

  Type: deb deb-src
  URI: http://mirror.example.org/debian-ppas/secured-ssh
  Suite: stable
  Section: main
  Description: security enhanced sshd
   This repo contains enhaned builds of sshd and some related
   utilities with vastly improved security options over the
   standard builds in Debian.
  Signing-Key:
   [*MY* signing key goes here]

There's a few problems with doing that:

 a) anybody whose traffic to example.org you can't intercept will
    get an error if they check that repo against the nominated signing key.
    if extrepos.d.n does minimal sanity checking before adding a repo,
    this makes this attack a non-starter afaics.

 b) if someone's trying to install a PPA for secured-ssh, why would they
    go through extrepos?

 c) if you've gotten someone to install your extrepo, and they'll agree to
    install things signed by your key, why not just point them directly
    at a server you control? if you do that, you can be much nastier,
    eg by serving a real secured ssh to most people, and a vulnerable
    ssh only to people you're trying to hack.

Running an extrepo by someone you don't trust at all is still crazy, just
as installing software written by someone you don't trust at all is crazy.
The improvement is for the case where:

 - you trust "Debian"
 - you trust whoever wrote/packaged the software by reputation
 - you don't have direct communication with the software author/packager,
   or their public key, etc

Havng an extrepo lets the software author/packager announce an extrepo id,
at which point any Debian user can obtain the same extrepo sources.list
entry. (There's still a potential mitm in *obtaining* the extrepo
id, but that's more easily mitigated the shorter it is)

> Which isn't much different to how a man-in-the-middle works nowadays on
> the installation of an archive-keyring by man-in-the-middle the site
> where the instructions are written down to add the sources.list entry
> and the key.
> 
> SSL CAs regularily mess up checking that I am really the owner of
> example.org I want to get a certificate for and extrepos.d.o would be
> basically a certificate authority, just not for SSL but for
> archive-keys.

SSL CAs associate a key with a site, so that when users see a site,
they know what key to trust. 

But extrepos is the other way around, you decide to trust the key when
you add the extrepo, after that, whichever URL you end up at just needs
to be using that key. And you can't easily middleman adding the extrepo
because that's signed (and dated?) via the extrepo key (which you got
when you installed extrepo.deb from main).

> So, what you might want to do is drop the archive key "somewhere" which
> is not /etc/apt/trusted.gpg.d/ and declare with this option where this
> keyring file is. Maintain this keyring in a -archive-keyring package and
> you can do key transitions easily. Maintain this package not in the
> third-party repository but in an extrepos.debian.org archive just
> containing -archive-keyring packages and you can do 'revokes' of keys by
> no longer including it in the package, which gives you the 'ping' to the
> extrepos.d.o service for free in a secure way as otherwise we had to
> figure out a way to sign the ping, ensure it isn't a replay attack and
> all that stuff more or less solved for packages.

I think it'd be better to maintain the extrepos keys via a script than a
single deb -- for one, a deb would have to be updated every time a new
extrepo gets created, and in any event, the user has to run some sort
of script to activate an extrepo anyway.

I'm thinking:

   $ sudo extrepo add securedssh-2e9c64

which then:

   1. contacts extrepos.debian.net to get the info bundle for
      securedssh-2e9c64
   2. verifies the signature on the bundle against extrepos' public key
   3. verifies the bundle is for "securedssh-2e9c64"
   4. unpacks the key into /usr/share/extrepos/
   5. unpacks the deb822 snippet into /etc/apt/
   6. (i think that's it?)

Accompany that with adding APT::Update::Pre-Invoke hook ("extrepo
check") that:

   1. contacts extrepos.debian.net to see if the info bundle for
      securdssh-2e9c64 has been updated or blacklisted
   2. if so, updates/disables the entry in /etc/apt

> Maybe I am just pessimistic, but I kinda doubt this would change
> anything for this class as you usually have to do the 'curl|sh' and
> similar dance because there is no debian repository [...]

Maybe. But at the moment, even if there /were/ a debian repository,
"curl|sh" would be easier than going through the hoops to add the repo
to your system, and it's pretty hard to verify that you're not being
mitm'ed ("how do I know the key I've got is actually the one you wanted
me to add?").

> – and not few people
> are on the 'creating one is too much work' camp which is why I mentioned
> signed debs in my last response as I think is a little more realistic to
> replace them… in like 1 of 100 cases as the rest is too "cool and hipp"
> to worry about "legacy distros" now that everything can and should be
> done in the cloud™ where security isn't a problem…

Yeah, I don't disagree. I'd like to have an answer for the people who
*do* care about security and legacy distros, though. At the moment, I
don't have one other than "become a DD or DM, and get the package into
Debian proper".

> > > > Oh, what about "add me" files which just add components? That can be
> > > > done already and is secure, but lets just imagine someone clicks the
> > > > "add me" file for Debian-main and after that the one for
> > > > Debian-main-contrib-nonfree. Pretty obvious that this shouldn't end up
> > > > creating two sources files, right? (+ the joy of detecting mirrors)
> > That's not obvious to me. First because, why would you be adding "debian
> > main" ever -- how do you have a Debian system without main? Second
> > because doesn't having duplicate deb lines in your sources.list work
> > fine anyway? It seems to for me. And third, if this is just for extrepos
> > anyway, having each extrepo have a unique base url seems plausible.
> No it isn't fine to have e.g
> deb http://httpredir.debian.org/debian sid main
> deb http://httpredir.debian.org/debian sid main contrib
> If you drop the 'main' from the second (or just the complete first) line
> everything is fine.

It seems fine even with the dupe to me? With:

deb http://http.debian.net/debian/ testing main contrib non-free
deb http://http.debian.net/debian/ testing main

I just get:

W: Duplicate sources.list entry http://http.debian.net/debian/ testing/main 
amd64 Packages 
(/var/lib/apt/lists/http.debian.net_debian_dists_testing_main_binary-amd64_Packages)
W: Duplicate sources.list entry http://http.debian.net/debian/ testing/main 
i386 Packages 
(/var/lib/apt/lists/http.debian.net_debian_dists_testing_main_binary-i386_Packages)

?

> But yes, multiple rewrites of this paragrpah turned it into a mess: The
> point was: if the repository has multiple components, you will
> eventually need to deal with merging in the funky gui tools adding
> sources.

Would this be solved by extrepos.d.n having a uniqueness constraint on the
base URI? That seems easy enough. (Users can then endit the sources.list
snippet to disable components if they like)

Cheers,
aj

Reply via email to