On Thu, Nov 10, 2016 at 12:39:40PM -0200, Henrique de Moraes Holschuh wrote: > I'd prefer if we enhanced apt transports to run a lot more protected > (preferably under seccomp strict) before any such push for enabling > https transports in apt. It would reduce the security impact a great > deal.
I am helplessly optimistic, so I will say it again even if the past tells me it pointless: Anyone in any way interest in improvements is more than welcome to join deity@l.d.o / #debian-apt. Very few things get done by just talking on d-d@ about nice to haves. > Mind you, at fist look it seems like apt transports will *run as root* > in Debian jessie. HOWEVER I didn't do a deep check, just "ps aux" while > apt was running. And I didn't check in unstable. So, I (hopefully) > could be wrong about this. For jessie you are right. The few of us took an awful lot of time to basically reimplement many parts of the acquire subsystem in the last few years. You can watch Michael talk about it at DC14, me at DC15 and Julian at DC16 if you like, but the very basic summary is that in stretch onwards all apt methods run effectively as _apt:nogroups (and with no-new-privs) & apt itself requires repositories to be signed and expects more than just SHA1 or MD5 (as usual, that applies to everything related to apt like aptitude, synaptics, packagekit, apt-file, …). There is still much we wanna do, but for now we are actually happy that we seem to have managed to satisfy all the people who responded to those changes: The army of complainers that it breaks their firewalls, strange so called sneaker net abominations or other interesting workflows[0] … > Can you imagine trying to contain an exploit in the wild that will take > advantage of people trying to update their systems against said exploit > to spread even further? Well, this is exactly what would happen. We Let the code with no bugs cast the first stone – you could just as well say that any http bug is if wrapped in https less critical. libcurl depends on a crapload of stuff we don't actually need because we use it just for https and not for ftp, samba, …. And then most TLS exploits tend to be in tricking it to consider a cert valid while it isn't, which is a big problem for most things, but for apt those kind of bugs are a lot less critical as we don't trust the transport layer anyhow (if we treat it more as a MITM annoyance instead of one-and-only security). As such, completely non-empirical of course, but I think it would be a net-benefit to have https sources available for use by default even if its overrated in this context – but you will only die very tired if you try to explain why https-everywhere is a requirement for your browser and even most (language specific) package managers to add a tiny layer of security to them, but our beloved apt doesn't strictly need it for security (but happily accepts the tiny layer as addition). As already said, we are open to consider replacing libcurl with a suitable alternative like e.g. using libgnutls directly – but see optimistic paragraph above, I still hope that a volunteer will show up… (as the biggest TLS exploit is usually the implementor who hasn't worked with the API before and I haven't). And I would still like to have some for a-t-tor, too. The package is even way smaller than even the smallest node packages [SCNR] nowadays and someone with an eye for detail, integration and documentation could do wonders… but I start to digress. Best regards David Kalnischkies [0] https://xkcd.com/1172/
signature.asc
Description: PGP signature
