(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 ) 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. 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. > > 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. >> 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? 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… > > 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". > 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. Also, a single deb is easy to review (see above) compared to an entire repository and it naturally expires on changes. 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) 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, but if I don't the whitelisting is only an annoyance for me as its at most a resigning away and given that this means work by an (for me) external body, it actually encourages to be slightly bad as a way of least resistance as I just need static linking, embedding and/or crude package renames and a wildcard to avoid praying and waiting for this external body to sign my changed whitelist. Accident protection you mentioned, well, yes, but that is bonus and at first it was suggested as a security feature which it isn't. aka: Bonus feature I would move to another proposal. > > > 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? The point here was that you said above as an argument for the whitelist that a random repository can't ship libc6 then. I argued further above that it isn't important for an attacker to use well known package names like libc6 as he just needs to target the most-used package of the repository he can infect. This field even declares which packages that would be. 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. Best regards David Kalnischkies
Attachment:
signature.asc
Description: Digital signature