On Wed, Jan 26, 2022 at 2:24 AM Christian Brauner <brauner@xxxxxxxxxx> wrote: > > On Tue, Jan 25, 2022 at 05:18:02PM -0500, Paul Moore wrote: > > On Tue, Oct 12, 2021 at 10:27 AM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > > > On 10/12/2021 3:32 AM, Christian Brauner wrote: > > > > On Mon, Oct 11, 2021 at 03:40:22PM -0700, Casey Schaufler wrote: > > > >> The usual LSM hook "bail on fail" scheme doesn't work for cases where > > > >> a security module may return an error code indicating that it does not > > > >> recognize an input. In this particular case Smack sees a mount option > > > >> that it recognizes, and returns 0. A call to a BPF hook follows, which > > > >> returns -ENOPARAM, which confuses the caller because Smack has processed > > > >> its data. > > > >> > > > >> Reported-by: syzbot+d1e3b1d92d25abf97943@xxxxxxxxxxxxxxxxxxxxxxxxx > > > >> Signed-off-by: Casey Schaufler <casey@xxxxxxxxxxxxxxxx> > > > >> --- > > > > Thanks! > > > > Note, I think that we still have the SELinux issue we discussed in the > > > > other thread: > > > > > > > > rc = selinux_add_opt(opt, param->string, &fc->security); > > > > if (!rc) { > > > > param->string = NULL; > > > > rc = 1; > > > > } > > > > > > > > SELinux returns 1 not the expected 0. Not sure if that got fixed or is > > > > queued-up for -next. In any case, this here seems correct independent of > > > > that: > > > > > > The aforementioned SELinux change depends on this patch. As the SELinux > > > code is today it blocks the problem seen with Smack, but introduces a > > > different issue. It prevents the BPF hook from being called. > > > > > > So the question becomes whether the SELinux change should be included > > > here, or done separately. Without the security_fs_context_parse_param() > > > change the selinux_fs_context_parse_param() change results in messy > > > failures for SELinux mounts. > > > > FWIW, this patch looks good to me, so: > > > > Acked-by: Paul Moore <paul@xxxxxxxxxxxxxx> > > > > ... and with respect to the SELinux hook implementation returning 1 on > > success, I don't have a good answer and looking through my inbox I see > > David Howells hasn't responded either. I see nothing in the original > > commit explaining why, so I'm going to say let's just change it to > > zero and be done with it; the good news is that if we do it now we've > > > It was originally supposed to return 1 but then this got changed but - a > classic - the documentation wasn't. I'm shocked! :) Thanks Christian. -- paul-moore.com