[Please note: This e-mail is from an EXTERNAL e-mail address] 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
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss