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@xxxxxxxxxxxxxxxx>
---
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);
