[PATCH 1/1] NAX LSM: Add initial support support
J Freyensee
why2jjj.linux at gmail.com
Tue Aug 10 04:52:07 UTC 2021
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
More information about the Linux-security-module-archive
mailing list