Hey Thijs.
On Thu, 2014-06-12 at 19:31 +0200, Thijs Kinkhorst wrote:
> You raise a lot of broad concerns under the header "holes in secure apt" which
> I'm afraid does not much to get us closer to a more secure Debian.
Well I admit, that first this is just a lot of words... but I think
that's the first what would need to be done - i.e. agreeing on what we
actually want... and decisions here are probably more upon core Debian
developers (I mean those which are maintaining/developing) the affected
systems and have the necessary insight.
Secondly, given the nature of these issues - they are rather deeply in
the Debian core packages and core (i.e. the build system) - it's
probably not that easy for people other than those
maintainers/developers to really move something.
For example, Thomas mentioned that things would have been more secure if
the buildds and e.g. pbuilder pulls in debian-keyring automatically and
verify maintainer signatures.
So on suggestion of mine would have been: generally do that and only
allow tools like pbuilder not do to so, when some special flag is given.
But I'm far too less into the whole infrastructure so that I could now
whether it works out in practise.
> Not many
> people will object that making Debian even more secure is a bad idea; it just
> needs concrete action, not a large list of potential areas to work on.
Well I'd guess the later is the first step, isn't it?
Taking inventory:
- which tools do we have that obviously directly need secure APT to be
used
- APT, aptitute, etc.
- pbuilder, qemubuilder, piuparts, etc.
- [c]debootstrap
- git-buildpackage
- libraries? python-debian and friends? (especially some
perl/python/php libaries seemed to never really verified any
certificates with SSL per default, until recently)
- which things can be used for high level attacks (downgrading, blocking
attacks), like apt-listbugs, apt-listchanges, debsecan,
debian-security-support, etc. (e.g. attacking a user by not showing him
that a critical bug has been found or fixed which the user must react
on)
- which tools that are probably not directly security critical use
APT/repo-related data in an unverified way
e.g. apt-file
- at which higher levels can we tighten security even more
E.g. currently Release files seem to have a rather large validity, for
example my current one:
> Date: Mon, 16 Jun 2014 09:03:47 UTC
> Valid-Until: Mon, 23 Jun 2014 09:03:47 UTC
Given that we often have very nasty zero-days,... these 7 days seem
pretty long to me.
Our security team is usually very fast and we have fixes often hours
after they're released... so these long validity times give an attacker
too many additional days.
- how may people use our tools in "invalid" ways
- do all tools like apt give non-zero exit codes as soon as the
slightest hint for anything security problematic was found?
- may people e.g. use the contents from /var/{lib|cache}/apt/ ,...
trusting that these are always valid, but they might not (possible
races?)
- which tools do we have that circumvent the package management system
(and/or the security team) altogether
(those downloader packages, Mozilla-stuff and other things that install
plugins from the web, tools like clamav, or rkhunter, that may download
stuff from the web)
- which services do we offer (alioth, or things like paste.debian.net)
that could may be used in a way relevant for security,... which are not
tightened up enough.
If e.g. the security team would share important fixes with the
maintainers via paste.d.n... but code could be forged during that steps
(and no, I don't trust any GANDI certs,... than it may be a simple but
effective attack.
> I suggest that you focus on one of those aspects of your email and take some
> concrete action to get it addressed. For example this part:
Well the problem is,.. if we pick out one,... all other get forgotten...
And as you can imagine it's not up to me to decide any of these ideas...
and at best difficult to implement them alone.
Just take the IMHO too long expiry dates mentioned above... I can't just
decide this (it's probably the ftp masters who do that?)
> I think a better way than to create such a policy would be to create a simple
> framework that does in-package downloading "right" and that downloader
> packages can depend on and call from their scripts (a bit like dbconfig-
> common). An existing technical solution will probably be more quickly adopted
> by the various packages than a set of requirements, and improvements need to
> be made in only one place.
Well I think both would be needed...
a) clear policy which tells what are packages allowed to do and what not
For a package like torbrowser-launcher, verifying code just via the
upstream GPG keys is of course cheap (however, having the security
issues I've mentioned before), since if it would be done via hard coded
hashes, the debian package needs to update everytime a new upstream
version comes out.
Before it makes sense to write any framework, Debian should decide what
it allows and what not.
> If you create something like that I'd gladly use it in the downloader package
> I maintain (msttcorefonts - which does check hashes of downloaded stuff, btw)
> and I'm willing to spend time with you on the integration and to see what may
> be required or missing for my package to use it. If we show that it works for
> this package, others will surely follow. You just need to take the first step.
Mhh... well first of all: I think we obviously cannot do anything for
packages like torbrowser-launcher,... there it's really the whole
program which does the downloading... and not just a maintainer script.
So I guess we can/should only focus an such downloaders, where the
package itself (i.e. the maintainer scripts) are doing the
downloading,... and probably just forbid any other packages ;-)
How should it happen? Just some shell script, which is sourced by the
maintainer scripts, that provides "secure" download functionalities...
or some dh module?
For the "technique" itself I'd suggest the following:
- secure the download by one (ore more) hash sums,... where people are
recommended to use the "most secure" one (e.g. currently some SHA3 or
SHA512).
As long as the package is kept up to date, we should avoid any attacks
like blocking/downgrading attacks.
- only verify https or OpenPGP from upstream in addition to the hard
coded hash sum.
- make sure any downloaded files are extracted securely (i.e. to some
empty dir, removing any leading / from tar/zip/etc., perhaps even making
chowning 0:0 and setting sane permissions before.
Anyway I think the core message is:
For security it's not enough if some lone warriors hack some code...
even if their code is perfectly secure, the glue is likely still
missing... the bigger picture is left out.
I think security here must be a broader joint effort... especially of
some core Debian maintainers...
Cheers,
Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature