Re: [RFC PATCH 0/3] Including file signatures in .deb packages]
On Mon, 2014-08-11 at 15:13 +0200, Guillem Jover wrote:
> Hi!
>
> I think perhaps you might have meant to send this to the debhelper
> maintainers? Otherwise here's some comments.
Thank you for the feedback! The patches went through a number of
iterations. The initial one modified dpkg directly. Does it make sense
to copy both mailing lists on this discussion of adding signatures
to .deb packages?
> On Fri, 2014-08-08 at 12:57:38 -0400, Mimi Zohar wrote:
> > We're looking to include file signatures in the different package
> > formats (eg.rpm, deb) and install them as 'security.ima' extended
> > attributes(xattrs). These signatures could then be used to enforce
> > local file integrity and included in the IMA measurement list to
> > provide file provenance.
>
> I've pending to go back to the discussion about adding signatures to
> the .deb files (bug #340306), hopefully before the freeze.
Thank you for the reference to the previous discussions.
> Those
> signatures should probably be stored (if at all) in the dpkg database,
> as there's no guarantee the filesystem would support xattr, and this
> will be done automatically as long as this stuff is shipped in a
> file in the .deb control area. Also if an attacker could modify the
> file they might as well be able to modify the xattrs, so I'm not sure
> this adds any security. Integrity sure, but we've got md5sums already
> which should be fine for that, and the «dpkg --verify» command now.
In this design are signatures verified before the file is read/executed
or is it a separate, out of band process that is run independently? It
sounds like the latter.
IMA-appraisal, based on policy, enforces local file integrity. Once
3.17 is released, certificates, containing a key used to verify file
signatures, will need to be signed by a system trusted key (UEFI/shim db
or builtin), before being added to the IMA keyring. This extends the
UEFI signature chain of trust, which is rooted in HW, to the OS.
> > The existing md5sums file contains the file hash and name for each file
> > included in the package. This makes it the most logical place for
> > storing the file signatures, other than the hash being md5. For now,
> > this patch set assumes the existence of an equivalent sha256sums file.
> > (For convenience, I've duplicated the dh_md5sums helper naming it
> > dh_sha256sums.)
>
> If such a new command is desirable, I'd go instead for something like
> dh_checksums or similar so that it does not need to change every time
> a different algo is added or switched to.
Agreed.
thanks,
Mimi
Reply to: