Re: [PATCH v1 4/8] LSM: Maintain a table of LSM attribute data
Paul Moore <[email protected]>
| Newsgroups | com.redhat.linux-audit,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CAHC9VhQzP0Fz4O9dJLy2hQrMK-2gDjEDBsJw=-2Fvr9jiva1Hg@mail.gmail.com> |
On Wed, Oct 26, 2022 at 8:38 PM Casey Schaufler <[email protected]> wrote: > On 10/25/2022 11:00 PM, Greg KH wrote: > > On Tue, Oct 25, 2022 at 11:45:15AM -0700, Casey Schaufler wrote: > >> As LSMs are registered add their lsm_id pointers to a table. > >> This will be used later for attribute reporting. > >> > >> Signed-off-by: Casey Schaufler <[email protected]> > >> --- > >> include/linux/security.h | 17 +++++++++++++++++ > >> security/security.c | 18 ++++++++++++++++++ > >> 2 files changed, 35 insertions(+) > >> > >> diff --git a/include/linux/security.h b/include/linux/security.h > >> index ca1b7109c0db..e1678594d983 100644 > >> --- a/include/linux/security.h > >> +++ b/include/linux/security.h > >> @@ -138,6 +138,23 @@ enum lockdown_reason { > >> > >> extern const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1]; > >> > >> +#define LSMID_ENTRIES ( \ > >> + 1 + /* capabilities */ \ > > No #define for capabilities? > > Nope. There isn't one. CONFIG_SECURITY takes care of it. I guess we might as well use the existing pattern just in case this header ever gets pulled into somewhere unexpected. (IS_ENABLED(CONFIG_SECURITY) ? 1 : 0) + ... -- paul-moore.com -- Linux-audit mailing list [email protected] https://listman.redhat.com/mailman/listinfo/linux-audit