On Thu, 2014-06-12 at 16:54 +0200, Christoph Anton Mitterer wrote: > On Thu, 2014-06-12 at 08:58 +0200, Thijs Kinkhorst wrote: > > If you want to discuss your plans to work on improving APT, you're more > > on-topic at deity@lists.debian.org. > I think this goes beyond > just APT (even though APT is probably at the core)... One further thing I've forgot (I've had brought this up here before, but I think the situation is still not satisfying - so sorry for repeating myself): We have a number of packages which circumvent the package management system by downloading "normal" files (think of HTML files as downloaded by the susv[2,3,4] packages) or even code (like torbrowser-launcher). 1) Some used to do these downloads completely unverified and installed such files Situation has improved here now,... but the problem is that we might have missed packages which do such things. - I'm not sure whether there actually are or not, but there should be clear policies which regulate such behaviour, mandating that verifications must be done... - it should be somehow unified how those verifications are done... I mean it can't be that some packages use MD5 for that job... it's broken, there's no reason to use it. Full stop. 2) Then we have packages like torbrowser-launcher, which, AFAICS, uses the gpg keys of the upstream authors for verifying anthing that was downloaded. I haven't checked the code in detail, whether this is done correctly,.. but I'd after a first glance I'd see already two problems: - downgrading attacks: upstream doesn't use expiring signatures on their files... so an attacker might MitM, with an old copy of some vulnerable torbrowser +sigs... torbrowser-launcher probably happily accepts this, since there is a valid signature signed by one of the keys. - the owners of those GPG keys are more or less empowered to circumvent the FTP masters and the security team... anything they sign, and place on there servers, would be accepted by such package... if they were the attackers, they could even do this on a per user basis, so you have basically no chance of ever noting it. I guess the same issues apply e.g. to flashplugin-nonfree. 3) For packages like torbrowser-launcher or flashplugin-nonfree it's more or less clear that some downloaded (at least when you read the package description)... there are other packages where similar things may happen and this is not directly visible... like gnome-shell which gives the gnome-shell-browser-plugin (which is automatically enabled),... which I think is very unfortunate. With all that we must remember that Debian "promises" security to its users,... but as you can see, there are ways to easily attack that security or at least to circumvent the security team and security updates infrastructure of the package management system (i.e. aptitude/apt won't ever notice you, when a new flash player came out) I think there should be some clear policy on how packages are allowed to pull in external code/files and install them to the system: - How packages are technically allowed to pull in external code, I think verifications should be mandatory and IMHO that verification should be via hardcoded hash sum (i.e. NOT via some gpg key from upstream),... if a new upstream version comes out, a new package should be released with new hash sums and new download path. That way we protect against downgrading attacks, don't give control to non-debian developers and make sure that all people get the same code (which will make it much easier to find about intentional attacks in that code). After all, software should come in via the package management system and task shouldn't be delegated to downloader-packages or plugin-systems like from Mozilla or GNOME. - There could be standardised package header flags like,... - "installs-external-code": having that info just perhaps in the description is IMHO not enough - "not-security-supported": debian-security-support is nice,... but it's rather just description,... and not a easy way to find e.g. all packages on some system which are not security-supported. Ideally, package management systems should allow people to allow/disallow with such flags. - one should generally not allow to trust on https/x509 for downloading external code/files, since - like with OpenPGP - too much power is given to people not from Debian (actually much more than with OpenPGP, since anyone in the certificate chain will have full power)... - If verification via OpenPGP/X509 would stay (and as said, security wise this would be a bad idea)... then there should be some documents explaining how maintainers should do the download... i.e. it's stupid to just wget https://bar or to gpg --verify foo ... since the default locations for certs and keys may very well contain CAs/keys you don't wanna trust for software. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature