On 10/23/2017 12:14, Ian Lepore wrote:> Any thoughts on how to validate executables which are not elf binaries, > such as shell scripts, python programs, etc?I hadn't really thought in depth about it, as my main initial goal is signed kernel/modules, but I have given it some thought... Arguably the "right" way to do it would be to have the signing mechanism be part of the platform. For example, the JVM has conventions for jar signing. Not clear how this relates to shell scripts though. An alternative is something like the NetBSD veriexec framework, where there's MACs for specific files. That stuff is mostly orthogonal to the public-key approach I'm working on here, but there's possibly some interplay.
Eric McCorkle <eric at metricspace.net> wrote:> > Any thoughts on how to validate executables which are not elf binaries, > > such as shell scripts, python programs, etc? > > I hadn't really thought in depth about it, as my main initial goal is > signed kernel/modules, but I have given it some thought... >> An alternative is something like the NetBSD veriexec framework, whereYes, as previously mentioned the verified exec model deals with this neatly, and btw is more efficient than signing individual files - as is needed with ELF signing etc. I think for linux based platforms using IMA we need to generate 20-30k+ signatures, vs about a dozen for platforms using verified exec, verification is also more expensive I'm told.> there's MACs for specific files. That stuff is mostly orthogonal to the > public-key approach I'm working on here, but there's possibly some > interplay.Yes, you use the public key stuff to sign the manifests containing the blessed fingerprints. This is what Junos has been doing for more than a decade. Your "trust" database, might be useful in being able to extend that to general use. The trust model we use for Junos is deliberately very restrictive and thus of most use to embedded vendors.
On 10/23/2017 18:53, Simon J. Gerraty wrote:> Eric McCorkle <eric at metricspace.net> wrote: >>> Any thoughts on how to validate executables which are not elf binaries, >>> such as shell scripts, python programs, etc? >> >> I hadn't really thought in depth about it, as my main initial goal is >> signed kernel/modules, but I have given it some thought... >> > >> An alternative is something like the NetBSD veriexec framework, where > > Yes, as previously mentioned the verified exec model deals with this > neatly, and btw is more efficient than signing individual files - as is > needed with ELF signing etc. I think for linux based platforms using IMA we > need to generate 20-30k+ signatures, vs about a dozen for platforms using > verified exec, verification is also more expensive I'm told.Hmmm. There's advantages both ways, and I'll probably end up supporting both, as it's useful to have an in-band mechanism as well (also, I've already implemented signed ELFs). However, there is a definite advantage to having one signature for a huge number of MACs. Moreover, as I mention in the paper, the most feasible quantum-safe signature scheme at the present is SPHINCS, which has signatures about 40Kib in size. That's pretty terrible if you're signing each executable, but if you're signing 20-30k MACs at 16-32 bytes per code plus a path, suddenly a 40Kib signature doesn't look so bad anymore. It would be pretty great to roll out a trust infrastructure AND viable quantum-safe signatures. I could also see a combined scheme, say, where ELF files carry a UUID which indexes into a MAC manifest.