On Thu, Jul 23, 2015 at 10:14:21AM +0200, Wouter Verhelst wrote: > - Apt will try to download it from a default location in the repository > (or perhaps a location specified in the deb822 sources.list file > itself). What the heck is "it" in this sentence? I envision "deb822 sources.list" file, but reading the location of the file from the file itself seems a bit hard to pull of in practice… > - It may be GPG-signed by one or more keys. Apt should have a way of > configuring GPG keys that may be allowed to sign sources.list files, > preloaded with the set of keys in the Debian keyring. This will allow > system administrators in large environments to specify their own set > of keys allowed to sign repositories, as well as allowing downstreams > to add its own ways of trusting repositories. Using the Debian keyring as a preload means a) a big package pushed into the default set of installed packages 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. There is of course the general problem of if a signature by a 'random' DD actually assures anything. I mean, I have a key signed by a few DDs, does that mean I can repropose my key now for an archive? Sounds about right to me at least. So much for "a trusted path from Debian to [your] repository" as it is now my man-in-the-middled repository. (Did I say "I repropose"? That was the blackhat stealing my key of course) 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. If you thought the default CA trust store in a browser is (too) large, I am not sure what a 1000+ key trust store would be. Sounds for me like the wet dream of security folks (not)… 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? And god forbit that I might turn (even more) evil. Or the person I am selling the domain to in three months… (Or should I say the blackhat who did a hostile take over of my domain and now ships trojans to everyone with a sources.list signed by you). But yeah, you are not endorsing me, you just signed a document to give me root access on every machine you happen to be a trusted signer on – that is totally different. Some of this is a problem for an archive signing key as well, but the difference is that an archive signing key is signing a Release file which regularly changes, but a sources.list file hardly changes. It especially doesn't change in the last example with a domain takeover and there is no poor man's repository version of the web of trust. If you are adding archive signing keys it must be hundred percent bullet proof or all of apt-secure is broken. 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. > - 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? Lets imagine that your tool needs in version 2 two new obscure libraries: You will have a hard time convincing John Doe that he should update the list by hand after apt-get crapped out with an error message saying that much – on the other hand Jane Doe will be disappointed if you let apt-get change the list based on the wishes of the repository. And lets face it: Nobody will be happy if apt-get is asking a question about this as everyone will be trained to press 'yes' pretty quickly. Oh, and what about eid-libc6 provides+replaces libc6 ? Did I hear someone say package managers should interpret provides+replaces as an upgrade instruction? Oh, the fun I could have if I wouldn't be root on your system already… (not I, I mean the blackhat…) > - (It would be good if apt also added the ability to limit keys on a > per-repository basis, already suggested in the January 2014 discussion > but not yet implemented due to missing required infrastructure) I implemented that in the meantime (not released yet), but that is again mostly something to have a warm fuzzy feeling with, not something giving anything substantial. It fixes the hostile domain-takeover from above at the expense of raising again the question of who is responsible for keeping this information current – or trains Joe's to press 'ignore' on the resulting security errors. (Which is why I implemented enforcing a specific keyring as well, which you could keep uptodate via a -archive-keyring package, but still it's little more than a drop in the ocean as it's no answer in the bootstrap problem) > We could then also add a field "Default-Install:", ignored by apt but > honoured by a handler for the MIME type of sources.list files, that > would list a set of packages to install by default when adding this > repository. No practical difference between libc6 or eid. q.e.d. > At the same time, it would allow us to limit the possible "damage" > third-party repositories can do in several ways: > - Limit the keys with which they can sign their repositories; And this is a limit because… ? So my key (assuming you have it in your trust store) can't sign the Debian archive – buh huh. At least I can still sign "my" repository with it. Good enough for me – all I need to ship is an "update" of eid now… aka: If you trust a bad key you have already lost. > - Limit the packages they can override, very much in the same way we > limit DMs today; Expect that this limit is enforced at a central place, can be constantly updated and that the people hit by the limit are also the people who can 'easily' deal with the problem – or at least understand it. Very much unlike the way repositories and dependencies work today. Or to express it in your example: How should a user decide if a repository is allowed to ship libc6 or not? > - If the Pin-Priority: field as proposed by aj is implemented (doesn't > appear to be the case today), limit the impact the repository can > have. This is more a theoretic limit. Any normal repository will have a pin-value of at least 100 (NotAutomatic + ButAutomaticUpgrades) as everything else isn't very practical. So I have the guaranty that if I know a package name the user will have installed from this repository I have an upgrade and hence a way to run my maintainerscript as root – so where is this "limit the impact" exactly? Also, why should have a repository the right to declare its own pin value? Okay, they can opt for a low one, but does that mean I can get you to sign my sources.list file with a pin value of 1111 (wich gives me downgrades)? If such a field is implemented, that is strictly a user-set one only. A repository shouldn't be able to set it… In general I think we are talking about two different files here which just happen to have a similar format and the later can be a template for the first one. The deb822 sources.list (which in fact will have a '.sources' extension as we can't mix two different formats in '.list' – and no, there is no sources.sources, just sources.list.d/foo.sources) and your "add me" file which has the same syntax but is signed. You can't sign the first one as a user should be allowed to modify a configuration file… 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) Best regards David Kalnischkies P.S.: Ubuntu ppa's use https; I think hildon just ignored security completely but some time passed since I played with a stock Nokia N810. And last I heard Debian ppa's were supposed to be signed by the usual debian archive key(s), so no security problem here.
Attachment:
signature.asc
Description: Digital signature