[PATCH] LSM: add SafeSetID module that gates setid calls

[Kees Cook]

On Wed, Nov 21, 2018 at 8:54 AM <mortonm at chromium.org> wrote:
>
> From: Micah Morton <mortonm at chromium.org>
>
> SafeSetID gates the setid family of syscalls to restrict UID/GID
> transitions from a given UID/GID to only those approved by a
> system-wide whitelist. These restrictions also prohibit the given
> UIDs/GIDs from obtaining auxiliary privileges associated with
> CAP_SET{U/G}ID, such as allowing a user to set up user namespace UID
> mappings. For now, only gating the set*uid family of syscalls is
> supported, with support for set*gid coming in a future patch set.
>
> Signed-off-by: Micah Morton <mortonm at chromium.org>
> ---
>
> Sending a patch developed against the 'next-general' branch of the
> linux-security tree, since the previous patch versions wouldn't apply
> cleanly to 'next-general'.

I'm finally getting back around to this. Sorry for the delay!

A few general process notes:
- Please "version" your patches in the Subject (e.g. "[PATCH v3] LSM:
add SafeSetID ..."). This helps track discussion.
- Please include a "changes since last version below the first "---"
line, to summarize what has changed. This makes review faster for
people that have read a specific version but need to catch up (like
me) :)

> +/*
> + * TODO: Figuring out whether the current syscall number (saved on the kernel
> + * stack) is one of the set*uid syscalls is an operation that requires checking
> + * the number against arch-specific constants as seen below. The need for this
> + * LSM to know about arch-specific syscall stuff is not ideal. Is it better to
> + * implement an arch-specific function that gets called from this file and
> + * update arch/Kconfig to mention that the HAVE_SAFESETID symbol should only be
> + * selected for architectures that implement the function? Any other ideas?
> + */

What would Stephen's solution for this problem end up looking like? I
think avoiding the arch-specific-ness would be quite valuable.

I think adding a capability for this isn't the way to go (there is a
very painful history on adding capabilities). This feels much more
like a good mapping to an LSM (it's narrowing a privilege) with a very
specific policy.

-- 
Kees Cook