LSM stacking in next for 6.1?

[Paul Moore]

On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul at paul-moore.com> wrote:
> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
> > I would like very much to get v38 or v39 of the LSM stacking for Apparmor
> > patch set in the LSM next branch for 6.1. The audit changes have polished
> > up nicely and I believe that all comments on the integrity code have been
> > addressed. The interface_lsm mechanism has been beaten to a frothy peak.
> > There are serious binder changes, but I think they address issues beyond
> > the needs of stacking. Changes outside these areas are pretty well limited
> > to LSM interface improvements.
>
> The LSM stacking patches are near the very top of my list to review
> once the merge window clears, the io_uring fixes are in (bug fix), and
> SCTP is somewhat sane again (bug fix).  I'm hopeful that the io_uring
> and SCTP stuff can be finished up in the next week or two.
>
> Since I'm the designated first stuckee now for the stacking stuff I
> want to go back through everything with fresh eyes, which probably
> isn't a bad idea since it has been a while since I looked at the full
> patchset from bottom to top.  I can tell you that I've never been
> really excited about the /proc changes, and believe it or not I've
> been thinking about those a fair amount since James asked me to start
> maintaining the LSM.  I don't want to get into any detail until I've
> had a chance to look over everything again, but just a heads-up that
> I'm not too excited about those bits.

As I mentioned above, I don't really like the stuff that one has to do
to support LSM stacking on the existing /proc interfaces, the
"label1\0label2\labelN\0" hack is probably the best (only?) option we
have for retrofitting multiple LSMs into those interfaces and I think
we can all agree it's not a great API.  Considering that applications
that wish to become simultaneous multi-LSM aware are going to need
modification anyway, let's take a step back and see if we can do this
with a more sensible API.

I think it's time to think about a proper set of LSM syscalls.  We
have avoided this in the past for several reasons, but over the past
couple of decades the LSMs have established themselves as a core part
of Linux with many (all?) major Linux distributions shipping and
supporting at least one LSM; I think we can justify a handful of well
designed syscalls, and with Landlock we have some precedence too.
While I realize syscalls are not the only kernel/userspace API option,
but given the popularity of namespaces I believe a syscall based
kernel/userspace LSM API has a number of advantages over the other
options, e.g. procfs/sysfs, netlink, etc.

Further, I think we can add the new syscall API separately from the
LSM stacking changes as they do have standalone value.  This would
help reduce the size and complexity of the stacking patchset, which I
believe would be a very good thing.  Introducing the syscall API
sooner would also allow any applications wanting to make use of the
crazy new stacked-LSM world a head start as they could be modified
while the kernel patches were making their way through the
review/update/merge/release process.

Thoughts?

To help make things a bit more concrete, I put together a quick
strawman this afternoon to get the discussion started.  I'm definitely
not a syscall stylist so please consider this more as an idea and
discussion starter at this point; if we agree there is value in going
this direction I can put together a proper patchset to introduce the
new API ...

/* LSM_ID_XXX values 32 and below are reserved for future use */
#define LSM_ID_SELINUX 33
#define LSM_ID_SMACK 34
#define LSM_ID_TOMOYO 35
#define LSM_ID_IMA 36
#define LSM_ID_APPARMOR 37
#define LSM_ID_YAMA 38
#define LSM_ID_LOADPIN 39
#define LSM_ID_SAFESETID 40
#define LSM_ID_LOCKDOWN 41
#define LSM_ID_BPF 42
#define LSM_ID_LANDLOCK 43

/**
 * struct lsm_mod - LSM module information
 * @id: the LSM id number, see LSM_ID_XXX
 * @flags: LSM specific flags, zero if unused
 */
struct lsm_mod {
  unsigned int id;
  unsigned int flags;
};

/**
 * struct lsm_ctx - LSM context
 * @id: the LSM id number, see LSM_ID_XXX
 * @flags: LSM specific flags, zero if unused
 * @ctx_str: the LSM context string
 */
struct lsm_ctx {
  unsigned in id;
  unsigned int flags;
  char *ctx_str;
};

/**
 * lsm_enabled - Return information on the enabled LSMs
 * @lsm: individual LSM definitions
 * @count: the number of @lsm elements, updated on return
 * @flags: reserved for future use, must be zero
 *
 * Return information on the different LSMs enabled in the kernel.
 * On success, this function returns a positive number representing
 * the number of @lsm array elements, which may be zero if none are
 * enabled.  If the size of @lsm is insufficient, -E2BIG is returned
 * and the number of enabled LSMs is returned via @count.  In all
 * other failure cases, a negative value indicating the error is
 * returned.
 */
int lsm_enabled(struct lsm_mod *lsm, size_t *count,
  unsigned int flags);

/**
 * lsm_current_ctx - Return current tasks's LSM context
 * @ctx: the LSM contexts
 * @count: the number of @ctx elements, updated on return
 * @flags: reserved for future use, must be zero
 *
 * Returns the calling task's LSM contexts.  On success this
 * function returns a positive number representing the number of
 * @ctx array elements, which may be zero if there are no LSM
 * contexts assigned to the caller.  If the size of @ctx is
 * insufficient, -E2BIG is returned and the required number @ctx
 * elements is returned via @count.  In all other failure cases, a
 * negative value indicating the error is returned.
 */
int lsm_current_ctx(struct lsm_ctx *ctx, size_t *count,
  unsigned int flags);

-- 
paul-moore.com