Bug#892803: di-netboot-assistant: unsigned daily images

[Cyril Brulebois]

Matt Taggart  (2018-03-14):
> On 03/13/2018 10:28 PM, Cyril Brulebois wrote:
> 
> > What extra security would signing images bring here?
> 
> For me, assurance that nobody had interfered with the daily image that
> I will use to install a system. Many systems I install with a daily
> are for testing and get thrown away rather quickly (although often I
> don't know in advance which ones will end up sticking around longer).

Signing images on dillon doesn't bring you much security since files are
already served over HTTPS. That brings you no guarantee regarding a
possible interference on the porterbox it was built on, or regarding
other users on dillon.

> One reason in the past I have installed systems with a daily build
> that I know will stick around is due to needing support for new
> hardware at install time, where I couldn't just get an older install
> on the system with a stable d-i and then upgrade the kernel
> post-install. Usually things like drivers for a disk controller,
> newish filesystem features, or network drivers for doing a network
> install.

That's a well known use case. Official stable-backports d-i is being
worked on, even if irregularly because of other hard commitments.

> The testing alpha/beta/rc releases _do_ get signed right? Maybe that's
> a better solution for the above case where I need something newer than
> stable, but testing would in most cases be "new enough".

All releases (Alphas and RCs, Betas are gone) are the results of an
upload to the Debian archive, do get built on buildds, which are
restricted. That's rather different compared to the porterbox/dillon
setup mentioned above.

> But still thinking about daily...
> d-i.d.o does use https and has it's own Let's Encrypt issued cert, I
> think I could verify the cert and then check that the netboot.tar.gz
> matches the one published in
>   https://d-i.debian.org/daily-images/amd64/daily/SHA256SUMS
> Looking at the code, it looks like d-n-a already does the latter part
> I guess to prevent cases of download corruption, broken mirrors, etc.

Yes, HTTPS should do the trick.

> The default di-sources.list uses https for the daily images. And the
> code uses either wget or curl, both of which default to verifying
> certs via the normal system ca list. So it's already doing quite a bit
> to verify even the daily image sources. That's good, but if I was an
> attacker trying to mitm, I'd just need to find the weakest link in the
> CA cartel to issue me a d-i.d.o cert I could use for my mitm mirror.
> 
> This is a corner case for sure and if there is no reasonable way to
> solve it I think that's OK.
> 
> I think if I wanted to prove to myself the daily image came from
> debian, I could verify the cert used for d-i.d.o was indeed the known
> debian owned one, download the netboot.tar.gz/SHA256SUMS and stick
> them in the cache, and then use the --offline flag.

Which makes me wonder: If you're going to have so many concerns about
the trust chain, why don't you just build d-i locally?

(sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ time make -C build 
build_netboot USE_UDEBS_FROM=sid
[…]
real0m28.284s
user0m39.592s
sys 0m3.532s

Probably quicker/easier than doing cert pinning or so?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#892803: di-netboot-assistant: unsigned daily images

[Matt Taggart]

On 03/13/2018 10:28 PM, Cyril Brulebois wrote:


What extra security would signing images bring here?


For me, assurance that nobody had interfered with the daily image that I 
will use to install a system. Many systems I install with a daily are 
for testing and get thrown away rather quickly (although often I don't 
know in advance which ones will end up sticking around longer).


One reason in the past I have installed systems with a daily build that 
I know will stick around is due to needing support for new hardware at 
install time, where I couldn't just get an older install on the system 
with a stable d-i and then upgrade the kernel post-install. Usually 
things like drivers for a disk controller, newish filesystem features, 
or network drivers for doing a network install.


The testing alpha/beta/rc releases _do_ get signed right? Maybe that's a 
better solution for the above case where I need something newer than 
stable, but testing would in most cases be "new enough".


But still thinking about daily...
d-i.d.o does use https and has it's own Let's Encrypt issued cert, I 
think I could verify the cert and then check that the netboot.tar.gz 
matches the one published in

  https://d-i.debian.org/daily-images/amd64/daily/SHA256SUMS
Looking at the code, it looks like d-n-a already does the latter part I 
guess to prevent cases of download corruption, broken mirrors, etc.


The default di-sources.list uses https for the daily images. And the 
code uses either wget or curl, both of which default to verifying certs 
via the normal system ca list. So it's already doing quite a bit to 
verify even the daily image sources. That's good, but if I was an 
attacker trying to mitm, I'd just need to find the weakest link in the 
CA cartel to issue me a d-i.d.o cert I could use for my mitm mirror.


This is a corner case for sure and if there is no reasonable way to 
solve it I think that's OK.


I think if I wanted to prove to myself the daily image came from debian, 
I could verify the cert used for d-i.d.o was indeed the known debian 
owned one, download the netboot.tar.gz/SHA256SUMS and stick them in the 
cache, and then use the --offline flag.


--
Matt Taggart
tagg...@debian.org

Bug#892803: di-netboot-assistant: unsigned daily images

[Cyril Brulebois]

Matt Taggart  (2018-03-13):
> In the package provided di-sources.list file, in the daily section,
> there are the following comments,
> 
>   ## Daily netboot DI images (not signed?!?). Read:
>   # https://d-i.debian.org/daily-images/build-logs.html
>   # http://wiki.debian.org/DebianInstaller/Today

https://d-i.debian.org/daily-images/daily-build-overview.html is what
should be advertised. The other one was broken in the first place, and
is only kept for the debian-cd part which wasn't integrated in the
“new” view yet. The web server serving the cdimage logs has been shut
down anyway IIRC from a few weeks ago.

And yeah, nobody maintains /Today…

> It would be nice if the d-i daily's were signed, even if they had to
> use a different key that I would then need to install on the system so
> that this di-netboot-assistant check could use. Is there already a bug
> open requesting daily image signing? If not then maybe this one can be
> cloned and reassigned to the right place.

I don't think that's a reasonable thing to do. Images are built on
porterboxes, centralized on dillon, which is used for quite a number
of other things.

What extra security would signing images bring here?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#892803: di-netboot-assistant: unsigned daily images

[Matt Taggart]

Package: di-netboot-assistant
Version: 0.51
Severity: minor

When attempting to install a daily image I get the following


# di-netboot-assistant install daily --arch=amd64
I: Processing daily/amd64.
I: Downloading 'SHA256SUMS'.
E: Could not download 
'https://d-i.debian.org/daily-images/amd64/daily/../../../../Release' 
and/or 'Release.gpg'.


  * * * * * * * * * * * * WARNING * * * * * * * * * * * * *
  *   *
  *  Could not verify/find the signature of the release.  *
  *   *
  * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Download and install the image anyway? [y|N]:


In the package provided di-sources.list file, in the daily section, 
there are the following comments,


  ## Daily netboot DI images (not signed?!?). Read:
  # https://d-i.debian.org/daily-images/build-logs.html
  # http://wiki.debian.org/DebianInstaller/Today

which is a hint that this is likely to fail.

It would be nice if the d-i daily's were signed, even if they had to use 
a different key that I would then need to install on the system so that 
this di-netboot-assistant check could use. Is there already a bug open 
requesting daily image signing? If not then maybe this one can be cloned 
and reassigned to the right place.


But until something like that is possible I suggest a couple things:

* add something to the error message detecting when installing daily and 
explaining it's known that daily images currently aren't signed
* add some sort of override option for daily images to skip the check, 
printing a warning. This would allow for calling di-netboot-assistant 
from other tools (scripts, puppet, etc)
* update the comments in di-sources.list explaining dailys aren't signed 
and will result in the warning prompt
* the 'Today' URL in the comments no longer exists, I couldn't find a 
good replacement


--
Matt Taggart
m...@lackof.org