| Message ID | 20190228221933.2551-6-casey@schaufler-ca.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | LSM: Complete module stacking | expand |
On 2/28/19 5:18 PM, Casey Schaufler wrote: > When more than one security module is exporting data to > audit and networking sub-systems a single 32 bit integer > is no longer sufficient to represent the data. Add a > structure to be used instead. > > Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> > --- > include/linux/security.h | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/include/linux/security.h b/include/linux/security.h > index 13537a49ae97..a79fe8ef9d84 100644 > --- a/include/linux/security.h > +++ b/include/linux/security.h > @@ -73,6 +73,18 @@ enum lsm_event { > LSM_POLICY_CHANGE, > }; > > +/* Data exported by the security modules */ > +struct lsm_export { > + u32 selinux; > + u32 smack; > + u32 apparmor; > + u32 flags; > +}; > +#define LSM_EXPORT_NONE 0x00 > +#define LSM_EXPORT_SELINUX 0x01 > +#define LSM_EXPORT_SMACK 0x02 > +#define LSM_EXPORT_APPARMOR 0x04 Can this be generalized to avoid hardcoding the names of specific security modules in the field and symbol names? Possibly just an array of secids with the indices dynamically assigned by the infrastructure at registration time? We don't really want to have to patch this structure every time someone adds a new security module that needs audit and/or network facilities, right? > + > /* These functions are in security/commoncap.c */ > extern int cap_capable(const struct cred *cred, struct user_namespace *ns, > int cap, unsigned int opts); >
On 3/1/2019 6:00 AM, Stephen Smalley wrote: > On 2/28/19 5:18 PM, Casey Schaufler wrote: >> When more than one security module is exporting data to >> audit and networking sub-systems a single 32 bit integer >> is no longer sufficient to represent the data. Add a >> structure to be used instead. >> >> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> >> --- >> include/linux/security.h | 12 ++++++++++++ >> 1 file changed, 12 insertions(+) >> >> diff --git a/include/linux/security.h b/include/linux/security.h >> index 13537a49ae97..a79fe8ef9d84 100644 >> --- a/include/linux/security.h >> +++ b/include/linux/security.h >> @@ -73,6 +73,18 @@ enum lsm_event { >> LSM_POLICY_CHANGE, >> }; >> +/* Data exported by the security modules */ >> +struct lsm_export { >> + u32 selinux; >> + u32 smack; >> + u32 apparmor; >> + u32 flags; >> +}; >> +#define LSM_EXPORT_NONE 0x00 >> +#define LSM_EXPORT_SELINUX 0x01 >> +#define LSM_EXPORT_SMACK 0x02 >> +#define LSM_EXPORT_APPARMOR 0x04 > > Can this be generalized to avoid hardcoding the names of specific > security modules in the field and symbol names? Possibly just an > array of secids with the indices dynamically assigned by the > infrastructure at registration time? Yes, it can. I considered doing so very seriously. The reason not to do it is data lifecycle management. In today's code secids are often allocated on the stack and passed to code that holds the value indefinitely. If every assignment became an allocate and copy operation there would have to be reference counting and a lot more intelligence. The other advantage to the scheme used here is that an lsm_export can include something other than a secid should a security module so choose. It's not in this set, but I plan to change the Smack entry from a u32 to a struct smack_known *, making several operations much more efficient. Of course, that could be done using blob management, but the complexity increases yet again. > We don't really want to have to patch this structure every time > someone adds a new security module that needs audit and/or network > facilities, right? It's not a design that is being proposed without consideration. I seem to recall hearing the lifecycle arguments as a primary rationale for secids more than once. > >> + >> /* These functions are in security/commoncap.c */ >> extern int cap_capable(const struct cred *cred, struct >> user_namespace *ns, >> int cap, unsigned int opts); >> >
diff --git a/include/linux/security.h b/include/linux/security.h index 13537a49ae97..a79fe8ef9d84 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -73,6 +73,18 @@ enum lsm_event { LSM_POLICY_CHANGE, }; +/* Data exported by the security modules */ +struct lsm_export { + u32 selinux; + u32 smack; + u32 apparmor; + u32 flags; +}; +#define LSM_EXPORT_NONE 0x00 +#define LSM_EXPORT_SELINUX 0x01 +#define LSM_EXPORT_SMACK 0x02 +#define LSM_EXPORT_APPARMOR 0x04 + /* These functions are in security/commoncap.c */ extern int cap_capable(const struct cred *cred, struct user_namespace *ns, int cap, unsigned int opts);
When more than one security module is exporting data to audit and networking sub-systems a single 32 bit integer is no longer sufficient to represent the data. Add a structure to be used instead. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> --- include/linux/security.h | 12 ++++++++++++ 1 file changed, 12 insertions(+)