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: > > - 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…
I was thinking of having apt auto-update the file which is put there, so that if something changes (e.g., new signatures), we pick that up. Obviously it can't place it there by itself initially; that would be the responsibility of my proposed new tool. > > - 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 I'm not suggesting this be part of the base system. It should be part of the desktop task, probably, but that one is large enough already that this shouldn't make much of a difference. > 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) > There is of course the general problem of if a signature by a 'random' > 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 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". > 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) I'm not sure I can parse this part of your mail. The idea was: - A third-party developer wants to create a repository with packages - A DD checks the repository, sees that the packages are legitimate enough - The DD signs a sources.list file to express that the repository seems safe enough. That does not involve signing *keys*, does it? > 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)… I proposed that because it doesn't require any setup, and because we already trust DDs to be able to judge the quality of random packages, but I suppose we could create a system whereby the set of keys that can sign is much smaller, and some team/committee/whatever does the vetting, rather than "j random DD". The downside of such a system is, obviously, that it would require some extra red tape to work. > 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. > 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). Right. An obvious missing part in my proposal is that it would require the ability to revoke signatures somehow. Not sure how to accomplish that in a way that will scale without killing a central server or some such. Will give that some thought. [...] > If you are adding archive signing keys it must be hundred percent bullet > proof or all of apt-secure is broken. Yes. That's exactly why I'm soliciting feedback before going ahead and implementing 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. 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. Today, a blackhat who wishes to install a trojan onto a victim's system 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. By creating a way to allow us to do some basic checking of third-party repositories before allowing the repository to be enabled, we can give third-party developers a viable alternative to "just drop a .deb file on a website, and have people install that". On a side note, I was *not* suggesting this proposed tool add any configuration to apt without any prompting at all. If a user clicks on a link, that should result in a dialog box containing a "<program foo> wants to install <package x y z> from a third-party repository. Do you want to continue?", with a "detail" link containing the .sources file, and a "yes" and "no" button, or something along those lines. > > - 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. > 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. If your third-party repository needs a new library that doesn't match the whitelist, you will need to get your file resigned. That's why I was proposing the auto-update of those files. > 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…) Another reason why we'd need to be able to revoke. [...] > > 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. Not sure what you mean by this. Can you clarify? [...] > > - 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? A user shouldn't have to decide that; the person (DD) who signs the .sources file should. [...] > 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… Yes, that's probably a better way of doing things. I suppose the original "add me" file should probably be retained somewhere so we can do signature verification, but indeed, modification should remain possible. > 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 an implementational detail; not an unimportant one, but not yet relevant at this point of the discussion (just trying to figure out the big picture at this point) > 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. yes, but Debian's PPAs would not be very useful for third-party developers (because DD-only, sigh). -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150727224145.gc19...@grep.be
