<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Thanks for the pointers</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Scott<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">On 2021-09-23 12:11 p.m., Jeremy
      Stanley wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:20210923161125.xhe2hrxhyhuxdorn@yuggoth.org">
      <pre class="moz-quote-pre" wrap="">[Please note: This e-mail is from an EXTERNAL e-mail address]

On 2021-09-23 11:13:32 -0400 (-0400), Scott Little wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">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...
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
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.

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">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?
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">[...]

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):

    <a class="moz-txt-link-freetext" href="https://bugs.debian.org/766267">https://bugs.debian.org/766267</a>
    <a class="moz-txt-link-freetext" href="https://lists.debian.org/debian-dpkg/2014/08/threads.html#00006">https://lists.debian.org/debian-dpkg/2014/08/threads.html#00006</a>

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
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Starlingx-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Starlingx-discuss@lists.starlingx.io">Starlingx-discuss@lists.starlingx.io</a>
<a class="moz-txt-link-freetext" href="http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss">http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss</a>
</pre>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>