veyepar: Signing package contents: why and how

Author(s):	Matthew Garrett
Location	Buzz
Date	aug Thu 10	Days Raw Files
Start	11:00	First Raw Start	error-in-template
Duration	00:45:00	Offset	None
End	11:45	Last Raw End
Chapters
Total cuts_time	None min.

https://debconf17.debconf.org/talks/174/
raw-playlist raw-mp4-playlist encoded-files-playlist mp4 svg png

assets release.pdf Signing_package_contents_why_and_how.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:

Locked:

clear this to unlock

Locked by:

user/process that locked.

Start:

initially scheduled time from master, adjusted to match reality

Duration:

length in hh:mm:ss

Name:

Video Title (shows in video search results)

Emails:

email(s) of the presenter(s)

Released:

has someone authorised pubication

Normalise:

Channelcopy:

m=mono, 01=copy left to right, 10=right to left, 00=ignore.

Thumbnail:

filename.png

Description:

markdown

Debian has infrastructure to ensure that users obtain unmodified versions of packages, but once they've hit disk that chain of trust vanishes. debsums allows admins to verify that the packages hash to a value stored in the dpkg package database, but in the face of active attack that provides no guarantees - an attacker can simply modify the stored hashes to match their modified binaries. The easiest approach is to use a read-only filesystem, but what if there were a stronger way to provide these guarantees without making system updates more difficult?

IMA, the Integrity Measurement Architecture, provides an in-kernel mechanism for verifying that binaries match associated signatures stored in extended attributes alongside the executable. These signatures can be generated at any point in the packaging process, from package build to archive processing. And with a simple addition of functionality to dpkg (already in progress), these signatures can be written out at package install time, allowing users to configure systems such that distribution binaries won't run if they've been tampered with.

What needs to be done to make this possible in Debian? Is it worth the effort? And how do we do this in a way that avoids systems being locked down in ways that limit user freedom? This presentation will attempt to answer all of these questions.

Comment:

production notes