[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

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/

Attachment: signature.asc
Description: PGP signature

Reply to: