On Tue, Dec 10, 2019 at 11:20 AM Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > On 12/10/19 10:58 AM, Paul Moore wrote: > > On Tue, Dec 10, 2019 at 10:45 AM Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > >> On 12/10/19 10:04 AM, Paul Moore wrote: > >>> On Tue, Dec 10, 2019 at 9:59 AM Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > >>>> On 12/9/19 9:28 PM, Paul Moore wrote: > >>>>> With CONFIG_AUDIT enabled but CONFIG_SECURITY disabled we run into > >>>>> a problem where the lockdown reason table is missing. This patch > >>>>> attempts to fix this by hiding the table behind a lookup function. > >>>> > >>>> Shouldn't lsm_audit.c be conditional on both CONFIG_AUDIT and > >>>> CONFIG_SECURITY? When/why would we want it built without > >>>> CONFIG_SECURITY enabled? > >>> > >>> My first thought of a fix was just that, but I remembered that the > >>> capabilities code is built regardless of the CONFIG_SECURITY setting > >>> and I thought there might be some value in allowing for lsm_audit to > >>> be used in commoncap (although in full disclosure commoncap doesn't > >>> currently make use of lsm_audit). > >> > >> Seems contrary to normal practice, i.e. if/when commoncap grows a > >> dependency, it can be changed then. > > > > Okay, want to submit a tested patch? I really would like to get this > > fixed before today's linux-next run. > > In looking at it, I'm wondering if we could just change the Makefile to > use obj-$(CONFIG_SECURITY) instead of obj-$(CONFIG_AUDIT) for > lsm_audit.c. I think it might build just fine without CONFIG_AUDIT > since audit.h provides static inlines that boil away to nothing for > audit_log*() in that case. Offhand I don't see any support/examples of > specifying two different config options for an obj list in a Makefile. That should work too I think. > The other option would be to introduce its own CONFIG_LSM_AUDIT option > and select that option automatically for the modules that use it, which > would currently be selinux, apparmor, and smack. Then if you aren't > using any of those modules you can omit it from your kernel. This seems to be both the right thing to do, as well as overly complicated :) I'm not sure I have a strong preference at this point, other than getting it fixed. -- paul moore www.paul-moore.com
