Re: [PATCH v3 0/4] Introducing Hornet LSM

[Blaise Boscaccy <bboscaccy@linux.microsoft.com>]

KP Singh <kpsingh@kernel.org> writes:

[...]

> Now if you really care about the use-case and want to work with the maintainers
> and implement signing for the community, here's how we think it should be done:
>
> * The core signing logic and the tooling stays in BPF, something that the users
>   are already using. No new tooling.
> * The policy decision on the effect of signing can be built into various
>   existing LSMs. I don't think we need a new LSM for it.
> * A simple UAPI (emphasis on UAPI!) change to union bpf_attr in uapi/bpf.h in
>   the BPF_PROG_LOAD command:
>
> __aligned_u64 signature; 
> __u32 signature_size;

I think having some actual details on the various parties' requirements
here would be helpful. KP, I do look forward to seeing your design;
however, having code signing proposals where the capabilities are
dictated from above and any dissent is dismissed as "you're doing it
wrong" isn't going to be helpful to anyone that needs to use this in
practice.

Also, I don't think anyone actually cares, at least I don't, who calls
verify_pkcs7_signature or whatnot. Verifying signed binary blobs with a
private key is a solved problem and isn't really interesting.

Our requirements for code signing are just an extension of secure boot
and module signing logic:

* Prove all code running in ring zero has been signed
* Not trivially defeatable by root
* Ultimately, no trusted userspace components
* Secure from and not vulnerable to TOCTOU attacks
* Shouldn't be overly vulnerable to supply-chain attacks
* The signature checking logic and control paths should be human-readable
* Work easily and be backportable to stable kernels
* There should be a simple kconfig option to turn this on or off
* This solution needs to be in the mainline kernel

Hornet was implemented to meet those requirements, living in the LSM
subsystem, written in C. As of today, one cannot accomplish those
requirements via BPF-LSM, which is why C was chosen.

One can easily realize there is absolutely no way to have a single
one-size-fits-all signing solution for everything listed in
https://ebpf.io/applications/.

If you want to go the UAPI route, I would wholeheartedly recommend
making it extensible and having this data be available to the policy
LSMs.

enum bpf_signature_type {
  /* x509 signature check against program instructions only */
  BPF_SIGNATURE_PROG_ONLY = 0,
  /* x509 combined signature check against program instructions and used maps */
  BPF_SIGNATURE_PROG_USED_MAPS = 1,
  /* more of these to be determined via usage */ 
  ...
};

_aligned_u64 signature; 
__u32 signature_size;
__u32 signature_type;

The other option for solving this in the general is in-kernel
loaders. That's gotten pushback as well. 

-blaise