snip...
+#define pr_fmt(fmt) "NAX: " fmt + +#include <linux/capability.h> +#include <linux/cred.h> +#include <linux/ctype.h> +#include <linux/lsm_hooks.h> +#include <linux/mman.h> +#include <linux/sched.h> +#include <linux/securebits.h> +#include <linux/security.h> +#include <linux/sysctl.h> +#include <linux/uidgid.h> + +#define NAX_MODE_PERMISSIVE 0 /* Log only */ +#define NAX_MODE_ENFORCING 1 /* Enforce and log */ +#define NAX_MODE_KILL 2 /* Kill process and log */ + +static int mode = CONFIG_SECURITY_NAX_MODE, + quiet = IS_ENABLED(CONFIG_SECURITY_NAX_QUIET), + locked = IS_ENABLED(CONFIG_SECURITY_NAX_LOCKED); + +#define ALLOWED_CAPS_HEX_LEN (_KERNEL_CAPABILITY_U32S * 8) + +static char allowed_caps_hex[ALLOWED_CAPS_HEX_LEN + 1]; +static kernel_cap_t allowed_caps = CAP_EMPTY_SET; + +static int +is_privileged_process(void) +{ + const struct cred *cred; + kuid_t root_uid; + + cred = current_cred(); + root_uid = make_kuid(cred->user_ns, 0); + /* We count a process as privileged if it any of its IDs is zero + * or it has any unsafe capability (even in a user namespace) */ + if ((!issecure(SECURE_NOROOT) && (uid_eq(cred->uid, root_uid) || + uid_eq(cred->euid, root_uid) || + uid_eq(cred->suid, root_uid) || + uid_eq(cred->fsuid, root_uid))) || + (!cap_issubset(cred->cap_effective, allowed_caps)) || + (!cap_issubset(cred->cap_permitted, allowed_caps))) + return 1; + + return 0; +} + +static void +log_warn(const char *reason) +{ + if (quiet) + return; + + pr_warn_ratelimited("%s: pid=%d, uid=%u, comm=\"%s\"\n", + reason, current->pid, + from_kuid(&init_user_ns, current_cred()->uid), + current->comm);Have you considered writing to the audit log instead of the kernel messages directly? (not saying that this is necessarily better, but is there a reasoning to prefer one or the other here? Audit logs are often consumed by automated tools and it may be more pratical for people to detect and treat violations if the messages were pushed to the audit log - but conversely, that requires defining and maintaining a stable log format for consumers)
It's a good idea to writing to the audit log, HOWEVER I'd want to know what all the rest of the LSMs are doing in a case like this. If all of them just write kernel messages, I'd want this module to also write just kernel messages for consistency sake for use with say, log harvesters for a SIEM/XDR system solution.
Just in general I like the thought of this LSM. I used to work for a security company in which their cloud "watched" situations where mmap()/mprotect() would use anonymous executable pages for possible "dodgy" behavior.
Jay
