> From: Roberto Sassu [mailto:roberto.sassu@xxxxxxxxxx] > Sent: Thursday, July 7, 2022 1:01 PM > > From: KP Singh [mailto:kpsingh@xxxxxxxxxx] > > Sent: Thursday, July 7, 2022 1:49 AM > > On Wed, Jul 6, 2022 at 6:04 PM Daniel Borkmann <daniel@xxxxxxxxxxxxx> > > wrote: [...] > > > nit: when both trusted_keyring_serial and trusted_keyring_id are passed to > the > > > helper, then this should be rejected as invalid argument? (Kind of feels a bit > > > like we're cramming two things in one helper.. KP, thoughts? :)) > > > > EINVAL when both are passed seems reasonable. The signature (pun?) of the > > does seem to get bloated, but I am not sure if it's worth adding two > > helpers here. > > Ok for EINVAL. Should I change the trusted_keyring_id type to signed, > and use -1 when it should not be specified? I still have the impression that a helper for lookup_user_key() is the preferred solution, despite the access control concern. David, may ask if this is the correct way to use the key subsystem API when permission check is deferred? key_permission() is currently not defined outside the key subsystem. The first three functions will be exposed by the kernel to eBPF programs and can be called at any time. bpf_<key_helper> is a generic helper dealing with a key. BPF_CALL_2(bpf_lookup_user_key, u32, serial, unsigned long, flags) { ... key_ref = lookup_user_key(serial, flags, KEY_DEFER_PERM_CHECK); ... return (unsigned long)key_ref_to_ptr(key_ref); } BPF_CALL_X(bpf_<key_helper>, struct key, *key, ...) { ret = key_read_state(key); ... ret = key_validate(key); ... ret = key_permission(key_ref, <key helper-specific permission>); ... } BPF_CALL_1(bpf_key_put, struct key *, key) { key_put(key); return 0; } An eBPF program would do for example: SEC("lsm.s/bpf") int BPF_PROG(bpf, int cmd, union bpf_attr *attr, unsigned int size) { struct key *key; ... key = bpf_lookup_user_key(serial, flags); ... ret = bpf_key_helper(key, ...); ... key_put(key); } Thanks Roberto
