Messages in this thread | | | From | KP Singh <> | Date | Wed, 25 Mar 2020 15:35:28 +0100 | Subject | Re: [PATCH bpf-next v5 5/7] bpf: lsm: Initialize the BPF LSM hooks |
| |
On 23-Mär 15:12, Kees Cook wrote: > On Mon, Mar 23, 2020 at 02:58:18PM -0700, Casey Schaufler wrote: > > That's not too terrible, I suppose. What would you be thinking for > > the calls that do use call_int_hook()? > > > > rc = call_int_hook(something, something_default, goodnesses); > > > > or embedded in the macro: > > > > rc = call_int_hook(something, goodnesses); > > Oh yes, good point. The hook call already knows the name, so:
I learnt this the hard way that IRC that is passed to the call_int_hook macro is not the same as the default value for a hook
call_int_hook accomdates for a different return value when no hook is implemented, but it does expect the default value of the hook to be 0 as it compares the return value of the callbacks to 0 instead of the default value whereas these special cases compare it with the default value.
For example:
If we define the default_value of the secid_to_secctx to -EOPNOTSUPP, it changes the behaviour and the BPF hook, which returns this default value always results in a failure.
I noticed this when I saw a bunch of messages on my VM:
audit: error in audit_log_task_context
which comes from audit_log_task_context and calls security_secid_to_secctx which ends up being always denied by BPF.
In anycase, I am still adding the default value in LSM_HOOK and using them in the following hooks:
getprocattr -EINVAL inode_getsecurity -EOPNOTSUPP inode_setsecurity -EOPNOTSUPP setprocattr -EINVAL task_prctl -ENOSYS xfrm_state_pol_flow_match 1
Will send v6 out with these changes.
- KP
> > #define call_int_hook(FUNC, ...) ({ \ > int RC = FUNC#_default; \ > ... > > > -- > Kees Cook > >
| |