DigSig2 Design

• Linux kernel provides functions to handle X.509 certificates and PKCS#7 signatures, so stick to them instead of using GnuPG (unlike DigSig)
• Implement LSM hooks for mmap_file/file_mprotect (like DigSig)
• Implement trust chain handling to properly support different configurations

Signature placement

Traditionally all tools (except IMA) have placed signature into a custom-names section inside ELF file. This is bad from several point of view:

• It leaves possibility of section name conflict
• It does not integrate well with the rest of ELF infrastructure
• It requires to parse section and string table to locate signature

I'm considering following options for signature placement:

• SHT_NOTE section, which now becomes part of PT_NOTE segment. Now locating signature will involve parsing program headers and just notes section, which is easier and correlates better to what runtime loader is doing. However without distro support it is now impossible to use pristine software packages.
• Separate files, which are located next to ELF files in question. This will require additional VFS lookups to locate and load signature. Also this scenario has troubles with updating software on a target system, since signatures have to be updated in tight connection with signed software.
• Extended attributes (like IMA). This will allow one to extend the system to check data files in addition to checking the programs and libraries. However to properly support this option we might require to change package managers/implement additional hooks to set xattrs.

Root CA placement

• The easies way to provide Root CA certificate is to bundle it in signed kernel image. Image signature will be verified by the bootloader.
• Alternative options might involve Authenticated variables from UEFI
• or using TPM
• ????

Signature revocation

The ability to revoke a signature is as importand as an ability to sign the software. System administrator might want to revoke signatures because of individual software becoming unwanted on the target system (revoking single signature) or because of the signing key becoming unsecure (revoking key certificate).

While revoking certificates can be easily done through CRL mechanism (it is not fully supported in Linux kernel, but it would be easy to implement), revoking individual signatures requires additional setup.

It might be easier to implement both kinds of revocation by:

• implementing CRL support
• suggesting that each ELF signature is done using freshly generated key
• revoking corresponding certificate if software becomes unwanted

This is TBD later

Caching

Loading signatures and cryptographically verifying them will add additional overhead to software execution time, lowering the overall system performance. To neutralize this effect, it might be good to implement status caching (like IMA and DigSig do). It is necessary to review/reconsider both approaches before implementing proper status caching.