Re: Facilitating external repositories
Hi,
On Wed, Aug 12, 2015 at 08:37:49PM +0200, David Kalnischkies wrote:
> (now that I was ping'ed in reallife… lets finish this draft and make the
> discussion even longer as my previous mail was obviously not long enough
> ;) – or ignore the rambling entirely and skip to the last paragraph )
The joys of Debconf :-)
[...]
> On Tue, Jul 28, 2015 at 12:41:45AM +0200, Wouter Verhelst wrote:
> > On Sat, Jul 25, 2015 at 07:27:21PM +0200, David Kalnischkies wrote:
> > > On Thu, Jul 23, 2015 at 10:14:21AM +0200, Wouter Verhelst wrote:
> > > and b) the update state of this
> > > package: The package can happily contain revoked/expired keys (if
> > > everyone follows the <2 years expire recommendation every key will be
> > > expired well before the end of security support – not even mentioning
> > > LTS and apt can't just --refresh-keys as it can't verify the result).
> > > No longer DDs. Will not include new DDs. Same for DMs were the active
> > > state can vary faster based on the ping.
> >
> > That part is true enough. Not sure how to fix that.
> >
> > (we could possibly update against Debian's pgp keyserver, but that would
> > probably overload that server)
>
> --refresh-keys / --recv-keys can't be used on apts keyring if you aren't
> going to carefully check the result with your eyeballs (and the web of
> trust), aka: an absolute no-go for automation.
Right.
> So whereever you get the keyring updates from, it must be over a secure
> channel like via packages which (at least in the best cases) have
> overload, [long] replay attacks and co sorted out as a bonus, too. Just
> that this requires the package to be a very volatile data package, which
> it currently isn't.
agreed, so perhaps having a central signing key for external repository
configuration files is a better idea.
> > > There is of course the general problem of if a signature by
> > > DD actually assures anything.
> >
> > Well, I do think that if people have gone through the NM process,
> > they're generally capable of figuring out whether a package (or a
> > package repository) is going to cause problems. The signature a DD would
>
> d-mentors@ is a very lonely place if Debian has indeed ~1000 capable
> reviewers and I would argue that reviewing a single source package is
> less of an investment than reviewing an entire repository, especially
> given that…
>
>
> > make in this context is simply a vetting of "the packages in this
> > repository seem legitimate enough to not do anything that would break
> > your system outright".
>
> … your review comes with the repository-equivalent of DM-Upload-Allowed
> attached given that the repository content can change any minute.
True (which is the whole point of this proposal)
> >> Oh, and given that I got you to sign my example.org repo for me, does
> >> that mean you are endorsing my endeavor? I mean, pornview is a normal
> >> image viewer, hotbabe a good cpu monitor and sex my preferred input
> >> method (as a text editor). Any objections?
> >
> > Why would there be objections to that? My signature would solely be
> > about the technical quality of the packages, not about moral
> > implications.
>
> If you say so, but shouldn't that apply to d-mentors@ as well?
There is a huge difference between "here's a package with a horrible name for
the Debian archive" and "here's a repository, external to the Debian archive,
with some stuff with horrible names you might want to install"
> My feeling as an observer is that this isn't always the case.
>
> And by extension: Some gpg-users (including DDs) want to get to know me
> before signing my key given that I could be the human equivalent of
> hotbabe they don't want to be associated with…
That's perfectly fine, I don't want to force anyone to do anything.
> > > Sure, you are basically automating what is currently done by hand by
> > > many users, but as long as they do it by hand its their own fault
> > > – if you automate it to one-click they will rightly expect it to be
> > > secure.
> >
> > Are you saying we should stick to the current (completely insecure) way
> > of "tell people to copy-and-paste random shell snippets from the web"
> > because doing some minimal vetting and signing is not going to give them
> > the same level of security they get from installing stuff from the
> > Debian archive, and therefore not worth it?
> >
> > I think that's making the perfect be the enemy of the good.
>
> You can call it like that if you want, but I would say that I am trying
> to be devils advocate here to see if you have responses for the
> 'obvious' holes and gaps.
>
> Or in other words:
>
> > Sure, packages installed through my proposed scheme would carry less
> > trust with them; indeed, they are a more interesting target for a
> > blackhat than is the Debian archive. But my proposed scheme *is* an
> > improvement to today's situation.
>
> There is no less trust. There is either a "I trust you full so I give
> you root rights on my system" or "I don't trust you and therefore we are
> done here".
This is obviously wrong.
There is a "do I trust you enough to give you root on my system". But it
is not a black-and-white thing; it is a gliding scale.
Let's take the existing repository for google-chrome as an example. Doo
I trust google to provide packages which ship a webbrowser and nothing
more? Maybe. Do I trust them to provide packages which ship nothing
more than what they say it will ship? Yes. Do I trust them to ship a
package that doesn't do anything evil? Probably.
Is all of that trust enough for me to install their repository, giving
them full root on my system? That's a personal judgment call. I might do
that, or I might not.
But the claim that it is a black-and-white call for *Debian* to make, is
just wrong.
> > Today, a blackhat who wishes to install a trojan onto a victim's
> > just needs to trick said victim into calling 'gdebi' on a .deb file.
> > This *works*. It doesn't require *any* signature, and can do as much (or
> > even more) harm than with my proposed scheme. This is bad, IMO; I want
> > to fix that. I don't think it's a particular hole which we can
> > *completely* plug, but we can make it a smaller one. That's what my
> > proposal is trying to accomplish.
>
> If your goal is to replace 'one shot' installations of .deb files it
> would be better to head for signed deb files – there is quite a bit of
> an overhead between a single .deb file and creating an entire repository
> around this .deb file. Overhead not everyone wants to work with and/or
> is even needed for every usecase.
Sure, and that's perfectly fine. Yes, I agree that signed .deb files is
a worthy cause, it's just not something that would help *my* usecase,
and therefore isn't something I'm willing to spend my time on.
But there *are* use cases where the overhead *is* worth it, too.
> Also, a single deb is easy to review
> (see above) compared to an entire repository and it naturally expires on
> changes.
I think that depends on what kind of review you're aiming for.
If you're aiming for the kind of fail-safe review that would make it
impossible for a repository to break your system, then this scheme will
not work. Rather than trying to find a way to review something like
that, you should review a repository based on who is maintaining it.
Do the people maintaining it seem like responsible software developers,
who just want to make their own software easily installable to Debian
users? That seems like a legitimate thing, and the repository should be
signed.
Is this an existing repository maintained by a non-DD which just
contains a number of useful tools, all of which seem well-maintained?
That seems like it could be useful, but we might also instead invite
this person to maintain those packages in the Debian archive, instead.
Is this an empty repository, where the maintainer of the repository is
asking for a whitelist that includes core parts of Debian? That seems
dodgy, and we should refuse it.
In other words, you should try to review the intended use of the
repository, and try (using whitelists etc) to ensure that the repository
must follow that intended use, rather than limiting yourself to seeing
if the past use of the repository was legitimate.
That's not to say we shouldn't look at past use and/or technical things,
but that's a different matter.
> So, I think your today is a blackhat tricking a user to install the
> wrong archive signing key (potentially via a .deb or apt-key).
>
> The 'good' repositories already tell their users how to add the key
> "securely" which is usually in the form of looking for the right
> signature(s) on the key.
> I think that isn't an unimportant property of the manual style: The
> archive is declaring who can vet for it. This is especially important in
> your proposal as otherwise any rogue DD (or someone with access to a DD
> secret key)
Again, probably a better idea to have a central key then.
> can man-in-the-middle all repositories – and not only at first install
> but depending on the auto-update capability also later.
>
> Far more repositories (aka launchpad) 'trick' by using https for the
> download of the key. A few have the luxury of using another repository
> as their source for a key (mozilla.debian.net e.g. ships its key in
> a package included in Debian proper).
>
> My main problem is that the proposal has practically no details on what
> it will do about this…
>
>
> > > > - It may possibly add a limitation on the packages that can be
> > > > downloaded from the given repository (so that a package repository
> > > > cannot suddenly acquire a package "libc6", accidentally or otherwise).
> > > > This should allow for wildcards (e.g., in my specific situation this
> > > > field would contain "libbeid*, eid-*, beid-*")
> > >
> > > While a nice feature, hardly a security one as for an attacker it is
> > > only important to know which package to infect. libc6 is of course
> > > installed by everyone, so an "upgrade" in a bugged repository has the
> > > desired effect, but any person with your repository active will also
> > > have one of your packages installed – otherwise they wouldn't have the
> > > repository in the first place, right – so that feature gives a warm
> > > fuzzy feeling at best. Who cares in the end if the package I run my evil
> > > maintainer script with is called 'libc6' or 'eid' …
> > >
> > > btw: Who is controlling that whitelist?
> >
> > Whoever signs the .sources file.
>
> Against what is it a protection then?
>
> Clearly, if I want to do harm names aren't important,
They aren't unimportant, either.
A repository with a whitelist cannot install packages with names outside
that whitelist. It should also not be able to have packages with
Provides: or Replaces: headers outside that whitelist (so you can't ship
a package that claims to provide libc6). Since you cannot overwrite
other packages' files without Replaces:, you can't have a Package:
libbeidlibc6 which contains a file shipped by libc6.
[...]
> So, now that you have come all the way down here the short version:
> I would suggest getting a 'real' proposal written which has all the
> nitty gritty details about how to get the key installed on the system
> and how to prevent sources with revoked signatures to be installed on
> new systems (I guess removing them from the system they are already on
> is in general a lost cause, if the user isn't doing it by hand, but that
> is a problem we haven't solved anywhere anyway) defined without the
> "bonus" features as I am mainly talking about them as I can't criticise
> non-existing details and that seems to be taken as an indication that
> I am against it all, while I am "just" against the current 'holes' in
> the proposal.
Right.
I kindof like aj's proposal, and think it's probably the best way
forward, so I'm going to ditch what I'd been thinking about, and join
his ship ;-)
--
It is easy to love a country that is famous for chocolate and beer
-- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
Reply to: