[Starlingx-discuss] how to deal with loop dependent in building stage

[Jeremy Stanley]

On 2021-09-23 11:13:32 -0400 (-0400), Scott Little wrote:
> Thanks for the reply Jeremy, but I think your discussing the
> signing of packages as a whole, not the signing of files within
> packages.
> 
> I'm trying to learn a bit about how Linux IMA works...

Oh, thanks, I did indeed misread and thought you were asking about
an equivalent for the signing of .rpm files (packages), rather than
files within the packages for consumption by the kernel's integrity
measurement. Yes very different topics.

> The point of the feature is to have the executable files within
> the package (deb or rpm) carry signatures that the Linux kernel
> will validate before allowing the executable to run.
> 
> I'm still a little fuzzy on why the signatures on the executables
> need to be injected as part of packaging rather than building.  Is
> that a requirement for the chain of trust, or a conveniently
> centralized place to apply the policy to all packages?  And what
> does that mean for packages not directly built by StarlingX?
[...]

I'm a little fuzzy on the distinction between packaging and
building, since package building (in the Debian context at least)
drives executable compilation via policy included within the source
package.

Anyway, this looks like a relevant feature request for it along with
a proof of concept implementation (albeit with 7 years of cobwebs):

    https://bugs.debian.org/766267
    https://lists.debian.org/debian-dpkg/2014/08/threads.html#00006

The implementation looks fairly straightforward, the file signatures
would be generated when the packages are assembled and stored with
the file checksums normally tracked, then at installation those
signatures would be copied into extended filesystem attributes for
the relevant files, to be consumed by the kernel.

If this is of interest to the StarlingX community, it might be an
activity worth reigniting in Debian. It looks like the developers at
IBM who originally proposed support for it did not pursue it
further, at least that I can find any record of.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20210923/c409d5e4/attachment.sig>