LSM stacking in next for 6.1?

LSM stacking in next for 6.1?

[Casey Schaufler]

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.

Re: LSM stacking in next for 6.1?

[Paul Moore]

On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@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.

-- 
paul-moore.com

Re: LSM stacking in next for 6.1?

[John Johansen]

On 8/2/22 17:56, Paul Moore wrote:
> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@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.
> 

I am slowly working my way through the complete stack of patches again as
well. I have pulled them into a test branch for Ubuntu 22.10 and the
plan is to get them out into our -proposed kernels for broader testing in
the next couple of weeks

Re: LSM stacking in next for 6.1?

[Casey Schaufler]

On 8/2/2022 5:56 PM, Paul Moore wrote:
> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@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,

I have been and remain perfectly happy to do something completely
different provided it works. The interface_lsm scheme as implemented
is horrible, but it's better than the half dozen alternatives I've
proposed. At least no one has pointed out a use case that it can't
satisfy. I take full responsibility for mucking up "current".

>  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.
>

Re: LSM stacking in next for 6.1?

[Paul Moore]

On Tue, Aug 2, 2022 at 10:15 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 8/2/2022 5:56 PM, Paul Moore wrote:
> > On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@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,
>
> I have been and remain perfectly happy to do something completely
> different provided it works. The interface_lsm scheme as implemented
> is horrible, but it's better than the half dozen alternatives I've
> proposed. At least no one has pointed out a use case that it can't
> satisfy. I take full responsibility for mucking up "current".

Yes, I have no concerns around your willingness to do the Right Thing
Casey, whatever that may be :)

-- 
paul-moore.com

Re: LSM stacking in next for 6.1?

[Steve Grubb]

On Tuesday, August 2, 2022 8:56:21 PM EDT Paul Moore wrote:
>  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.

Why do we not have auid and sessionid in /proc/<pid>/status  ?

This has been needed for 10 - 15 years.

-Steve

Re: LSM stacking in next for 6.1?

[Paul Moore]

On Tue, Aug 2, 2022 at 10:34 PM Steve Grubb <sgrubb@redhat.com> wrote:
> On Tuesday, August 2, 2022 8:56:21 PM EDT Paul Moore wrote:
> >  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.
>
> Why do we not have auid and sessionid in /proc/<pid>/status  ?
>
> This has been needed for 10 - 15 years.

Nice thread hijack, but I believe you already know the answer to your
question Steve: submit a patch for review.

-- 
paul-moore.com

Re: LSM stacking in next for 6.1?

[Paul Moore]

On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@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

Re: LSM stacking in next for 6.1?

[Casey Schaufler]

On 9/2/2022 2:30 PM, Paul Moore wrote:
> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@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.

This is a compound problem. Some applications, including systemd and dbus,
will require modification to completely support multiple concurrent LSMs
in the long term. This will certainly be the case should someone be wild
and crazy enough to use Smack and SELinux together. Even with the (Smack or
SELinux) and AppArmor case the ps(1) command should be educated about the
possibility of multiple "current" values. However, in a container world,
where an Android container can run on an Ubuntu system, the presence of
AppArmor on the base system is completely uninteresting to the SELinux
aware applications in the container. This is a real use case.

I have chosen to use /proc interfaces for the stacking work for several
reasons. First and foremost, there are a painfully large number of system
applications that will never be modified to support multiple concurrent
LSMs, but that can be used successfully with the interface_lsm "hack".
Another is that it will take years to get a significant number of the
applications that can be changed updated. No one is even going to start
on that until kernel support is upstream.

> I think it's time to think about a proper set of LSM syscalls.

At the very least we need a liblsm that preforms a number of useful
functions, like identifying what security modules are available,
validating "contexts", fetching "contexts" from files and processes
and that sort of thing. Whether it is built on syscalls or /proc and
getxattr() is a matter of debate and taste.

>   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.

You can't script syscalls. A syscall interface is fine if you can also
update the entire system service application base for your distribution.
I don't see that as an option.

> Further, I think we can add the new syscall API separately from the
> LSM stacking changes as they do have standalone value.

I agree, but unless the new system calls take stacking into account
from their inception they're just going to be another interface that
makes stacking harder to accomplish.

>   This would
> help reduce the size and complexity of the stacking patchset, which I
> believe would be a very good thing.

The /proc interfaces interface_lsm and context are really pretty simple.

The addition of multiple subject labels to audit would be the same regardless
of /proc or syscall interfaces. We'd still need multiple LSM data in most
security blobs. The conversion of LSM hook interfaces from secids to lsmblobs
would still be required. As would the conversion from string+len pairs to
lsmcontext structures.

> 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.

A liblsm based on the /proc interfaces would address that as well.
Just as libselinux abstracts the /proc interfaces now.

> Thoughts?

I wish you'd suggested this three years ago, when I could have done
something with it. If stacking has to go on a two year redesign because
of this it is dead. We've spent years polishing the /proc interfaces.
Changed the names, the content, even bent over backwards to accommodate
the security module that refused to adopt an attr/subdir strategy. 

> 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 ...

I'm not objecting to this proposed API. I am objecting to the idea that
stacking can't progress without it.

>
> /* 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;

   const char *ctx_str;

or even

   const char *ctx;

err, and there are problems with passing this to a syscall.

> };
>
> /**
>  * 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);

Easy to implement in liblsm by parsing /sys/kernel/security/lsm.

> /**
>  * 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);

Your lsm_ctx struct won't do here. Where do the context strings go?
You can't have an unallocated pointer in a structure you pass to a syscall. 
This is the problem that led to the "lsm\0context\0lsm2\0context2\0"
version of attr/context.

... and you can fill this from /sys/kernel/security/lsm and
/proc/self/attr without using interface_lsm, so it can be implemented
today.

So while I agree that syscalls might be better, they are unnecessary
to support application updates. A liblsm that uses the file based interfaces
that are already there will work as well.

Re: LSM stacking in next for 6.1?

[Casey Schaufler]

On 9/2/2022 4:14 PM, Casey Schaufler wrote:
> On 9/2/2022 2:30 PM, Paul Moore wrote:
> ...
>> I think it's time to think about a proper set of LSM syscalls.
> At the very least we need a liblsm that preforms a number of useful
> functions

Which would include at least these. I used a different prefix so as
to avoid confusion with Paul's proposal. As these aren't syscalls they
may allocate memory. All can be done today.

struct lsm_context {
	char *lsm;	/* security module name */
	char *context;	/* value for this security module */
};

struct lsm_contexts {
	int count;
	struct lsm_context contexts[];	/* I think this is ok these days */
}

/*
 * lsm_self_contexts - get the security context of this process
 *
 * Returns an allocated lsm_contexts structure, or NULL on error.
 */
struct lsm_contexts *lsm_self_contexts(void)

/*
 * lsm_pid_contexts - get the security context of a process
 * @pid: process id of interest
 *
 * Returns an allocated lsm_contexts structure, or NULL on error.
 */
strcut lsm_contexts *lsm_pid_contexts(int pid)

/*
 * lsm_get_path_contexts - get the security context of a file
 * @path: path of interest
 *
 * Returns an allocated lsm_contexts structure, or NULL on error.
 */
struct lsm_contexts *lsm_get_path_contexts(char *path)

/*
 * lsm_set_path_contexts - set the security context of a file
 * @path: path of interest
 * @ctx: the context
 *
 * Note: needs to have deterministic behavior if 1st entry can be set
 * but 2nd can't.
 *
 * Returns 0 on success, a security module specific error on failure.
 */
int lsm_set_path_contexts(char *path, struct *lsm_contexts)

/*
 * lsm_free_contexts - free a lsm_contexts structure.
 */
void lsm_free_contexts(struct *lsm_contexts)

Also needs interfaces for SO_PEERSEC and SYSVIPC.

Re: LSM stacking in next for 6.1?

[Paul Moore]

On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 9/2/2022 2:30 PM, Paul Moore wrote:
> > On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
> >> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@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.
>
> This is a compound problem. Some applications, including systemd and dbus,
> will require modification to completely support multiple concurrent LSMs
> in the long term. This will certainly be the case should someone be wild
> and crazy enough to use Smack and SELinux together. Even with the (Smack or
> SELinux) and AppArmor case the ps(1) command should be educated about the
> possibility of multiple "current" values. However, in a container world,
> where an Android container can run on an Ubuntu system, the presence of
> AppArmor on the base system is completely uninteresting to the SELinux
> aware applications in the container. This is a real use case.

If you are running AppArmor on the host system and SELinux in a
container you are likely going to have some *very* bizarre behavior as
the SELinux policy you load in the container will apply to the entire
system, including processes which started *before* the SELinux policy
was loaded.  While I understand the point you are trying to make, I
don't believe the example you chose is going to work without a lot of
other changes.

Regardless of the above example, I want to be clear that I'm not
suggesting changes to the /proc interfaces.  Existing LSM aware
applications that use procfs for information would continue to work as
expected, it would just be the simul-multi-LSM aware applications that
would need to transition to the new syscall API to get all of the LSM
labels.

> > I think it's time to think about a proper set of LSM syscalls.
>
> At the very least we need a liblsm that preforms a number of useful
> functions, like identifying what security modules are available,
> validating "contexts", fetching "contexts" from files and processes
> and that sort of thing. Whether it is built on syscalls or /proc and
> getxattr() is a matter of debate and taste.

Why is it a forgone conclusion that a library would be necessary for
basic operations?  If the kernel/userspace API is sane to begin with
we could probably either significantly reduce or eliminate the need
for additional libraries.  I really want us to attempt to come up with
a decent kernel/userspace API to begin with as opposed to using the
excuse of a userspace library to hide API sins that never should have
been committed.

The LSM stacking work presents us with a unique opportunity to
modify/update/whatever the LSM kernel/userspace API, I don't want to
see us squander this chance on a hack.

> > 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.
>
> You can't script syscalls.

True.  However I don't see that as a blocker, trivial helper
applications can be written for those who wish to incorporate the new
syscall-based API into their scripts.  We would not be the first (or
the last) in this regard.

> A syscall interface is fine if you can also
> update the entire system service application base for your distribution.
> I don't see that as an option.

Once again, I'm not talking about removing the existing procfs
interface; existing applications would continue to work.  Only
applications which wanted to be simul-multi-LSM aware would need to be
modified, and those applications would need to be modified regardless
of if the procfs or syscall-based API was used.

> > Further, I think we can add the new syscall API separately from the
> > LSM stacking changes as they do have standalone value.
>
> I agree, but unless the new system calls take stacking into account
> from their inception they're just going to be another interface that
> makes stacking harder to accomplish.

They obviously would Casey, not only is that the context of the
discussion but my dummy example clearly had support for multiple LSMs.

> >   This would
> > help reduce the size and complexity of the stacking patchset, which I
> > believe would be a very good thing.
>
> The /proc interfaces interface_lsm and context are really pretty simple.

They are now, they are also a bit of a mess with legacy constraints
and they only get more complicated and messy with the LSM stacking
patches.  It is my opinion that a syscall-based API is cleaner and
easier for applications to use.

> The addition of multiple subject labels to audit would be the same regardless
> of /proc or syscall interfaces.

Yes, that's why I didn't bring up audit as it doesn't weigh on this
decision.  If you really want to include audit for some reason, I'll
simply remind you that I pushed back hard on overloading the existing
subj/obj fields with a multiplexed label format, asking for individual
subj/obj fields for each LSM.

> We'd still need multiple LSM data in most
> security blobs. The conversion of LSM hook interfaces from secids to lsmblobs
> would still be required. As would the conversion from string+len pairs to
> lsmcontext structures.

I'm not talking about kernel internal data structures Casey, I'm
talking about the kernel/userspace API.

> > 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.
>
> A liblsm based on the /proc interfaces would address that as well.

Perhaps a liblsm library would be useful for other reasons beyond this
discussion, but I don't want to use a userspace library as an excuse
to support an awful kernel/userspace API.

> > Thoughts?
>
> I wish you'd suggested this three years ago, when I could have done
> something with it. If stacking has to go on a two year redesign because
> of this it is dead.

I've never liked the combined label interfaces, see the mention of
audit in this email above.  I'm sure if you wanted to dig through all
of the mail archives I'm sure I've probably mentioned my dislike of
the combined label interface in procfs too; if not on the mailing list
then surely in-person at some point.  However, regardless of all that,
the key difference is that prior to a few months ago I didn't have to
worry about it quite as much as I do now.  Now I'm responsible for
standing up for the code that goes into the LSM tree and that means
both defending it as "good" and maintaining it long term; prior to a
few months ago that was, politely, "not my problem" :)

I can't currently in good conscience defend the kernel/userspace
combined label interfaces as "good", especially when we have a very
rare opportunity to do better.

-- 
paul-moore.com

Re: LSM stacking in next for 6.1?

[John Johansen]

sorry I am wayyyy behind on this, so starting from here

On 9/6/22 16:24, Paul Moore wrote:
> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@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.
>>
>> This is a compound problem. Some applications, including systemd and dbus,
>> will require modification to completely support multiple concurrent LSMs
>> in the long term. This will certainly be the case should someone be wild
>> and crazy enough to use Smack and SELinux together. Even with the (Smack or
>> SELinux) and AppArmor case the ps(1) command should be educated about the
>> possibility of multiple "current" values. However, in a container world,
>> where an Android container can run on an Ubuntu system, the presence of
>> AppArmor on the base system is completely uninteresting to the SELinux
>> aware applications in the container. This is a real use case.
> 
> If you are running AppArmor on the host system and SELinux in a
> container you are likely going to have some *very* bizarre behavior as
> the SELinux policy you load in the container will apply to the entire
> system, including processes which started *before* the SELinux policy
> was loaded.  While I understand the point you are trying to make, I
> don't believe the example you chose is going to work without a lot of
> other changes.
>
correct but the reverse does work. Where SELinux is running on the host
and AppArmor in the container. Obviously that is the simplified version
AppArmor is running on the host too but unconfined, has setup a policy
namespace for the container and is self stacking (bounding).

> Regardless of the above example, I want to be clear that I'm not
> suggesting changes to the /proc interfaces.  Existing LSM aware
> applications that use procfs for information would continue to work as
> expected, it would just be the simul-multi-LSM aware applications that
> would need to transition to the new syscall API to get all of the LSM
> labels.
> 

I can live with that. AppArmor and Smack have already landed private
interfaces and prefer them over the shared interface if they are
available.

>>> I think it's time to think about a proper set of LSM syscalls.
>>
>> At the very least we need a liblsm that preforms a number of useful
>> functions, like identifying what security modules are available,
>> validating "contexts", fetching "contexts" from files and processes
>> and that sort of thing. Whether it is built on syscalls or /proc and
>> getxattr() is a matter of debate and taste.
> 
> Why is it a forgone conclusion that a library would be necessary for
> basic operations?  If the kernel/userspace API is sane to begin with
> we could probably either significantly reduce or eliminate the need
> for additional libraries.  I really want us to attempt to come up with
> a decent kernel/userspace API to begin with as opposed to using the
> excuse of a userspace library to hide API sins that never should have
> been committed.
> 
I don't think its a foregone conclusion, its just that it has been
discussed several times, and all the interfaces have been nasty and
prebaked userspace code would be really nice to have.

There are other reasons to use a lib as well. Libs can help apps
pickup fixes/changes automatically.

> The LSM stacking work presents us with a unique opportunity to
> modify/update/whatever the LSM kernel/userspace API, I don't want to
> see us squander this chance on a hack.
> 

I do wish we had a better API from the beginning. I just hope it isn't
going to take another 10 years to get the API portion done.

>>> 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.
>>
>> You can't script syscalls.
> 
> True.  However I don't see that as a blocker, trivial helper
> applications can be written for those who wish to incorporate the new
> syscall-based API into their scripts.  We would not be the first (or
> the last) in this regard.
> 
>> A syscall interface is fine if you can also
>> update the entire system service application base for your distribution.
>> I don't see that as an option.
> 
> Once again, I'm not talking about removing the existing procfs
> interface; existing applications would continue to work.  Only
> applications which wanted to be simul-multi-LSM aware would need to be
> modified, and those applications would need to be modified regardless
> of if the procfs or syscall-based API was used.
> 
>>> Further, I think we can add the new syscall API separately from the
>>> LSM stacking changes as they do have standalone value.
>>
>> I agree, but unless the new system calls take stacking into account
>> from their inception they're just going to be another interface that
>> makes stacking harder to accomplish.
> 
> They obviously would Casey, not only is that the context of the
> discussion but my dummy example clearly had support for multiple LSMs.
> 
>>>    This would
>>> help reduce the size and complexity of the stacking patchset, which I
>>> believe would be a very good thing.
>>
>> The /proc interfaces interface_lsm and context are really pretty simple.
> 
> They are now, they are also a bit of a mess with legacy constraints
> and they only get more complicated and messy with the LSM stacking
> patches.  It is my opinion that a syscall-based API is cleaner and
> easier for applications to use.
> 

potentially if we can get one

>> The addition of multiple subject labels to audit would be the same regardless
>> of /proc or syscall interfaces.
> 
> Yes, that's why I didn't bring up audit as it doesn't weigh on this
> decision.  If you really want to include audit for some reason, I'll
> simply remind you that I pushed back hard on overloading the existing
> subj/obj fields with a multiplexed label format, asking for individual
> subj/obj fields for each LSM.
> 

how can I forget, what a pita :)

>> We'd still need multiple LSM data in most
>> security blobs. The conversion of LSM hook interfaces from secids to lsmblobs
>> would still be required. As would the conversion from string+len pairs to
>> lsmcontext structures.
> 
> I'm not talking about kernel internal data structures Casey, I'm
> talking about the kernel/userspace API.
> 
>>> 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.
>>
>> A liblsm based on the /proc interfaces would address that as well.
> 
> Perhaps a liblsm library would be useful for other reasons beyond this
> discussion, but I don't want to use a userspace library as an excuse
> to support an awful kernel/userspace API.
> 
>>> Thoughts?
>>
>> I wish you'd suggested this three years ago, when I could have done
>> something with it. If stacking has to go on a two year redesign because
>> of this it is dead.
> 
> I've never liked the combined label interfaces, see the mention of
> audit in this email above.  I'm sure if you wanted to dig through all
> of the mail archives I'm sure I've probably mentioned my dislike of
> the combined label interface in procfs too; if not on the mailing list
> then surely in-person at some point.  However, regardless of all that,
> the key difference is that prior to a few months ago I didn't have to
> worry about it quite as much as I do now.  Now I'm responsible for
> standing up for the code that goes into the LSM tree and that means
> both defending it as "good" and maintaining it long term; prior to a
> few months ago that was, politely, "not my problem" :)
> 
> I can't currently in good conscience defend the kernel/userspace
> combined label interfaces as "good", especially when we have a very
> rare opportunity to do better.
> 

so I am going to grab and hold onto
>>> Further, I think we can add the new syscall API separately from the
>>> LSM stacking changes as they do have standalone value.
>>

what I think Paul is saying is we can move the LSM stacking patches
forward by removing the combined label interface. They won't be as
useful but it would be a huge step forward, and the next step could
be the syscall API.

Re: LSM stacking in next for 6.1?

[Casey Schaufler]

On 9/6/2022 5:10 PM, John Johansen wrote:
> sorry I am wayyyy behind on this, so starting from here
>
> On 9/6/22 16:24, Paul Moore wrote:
>> I can't currently in good conscience defend the kernel/userspace
>> combined label interfaces as "good", especially when we have a very
>> rare opportunity to do better.
>>
>
> so I am going to grab and hold onto
>>>> Further, I think we can add the new syscall API separately from the
>>>> LSM stacking changes as they do have standalone value.
>>>
>
> what I think Paul is saying is we can move the LSM stacking patches
> forward by removing the combined label interface. 

Do you mean /proc/self/attr/interface_lsm? /proc/.../attr/context?

> They won't be as
> useful but it would be a huge step forward, and the next step could
> be the syscall API.

Re: LSM stacking in next for 6.1?

[John Johansen]

On 9/6/22 17:39, Casey Schaufler wrote:
> On 9/6/2022 5:10 PM, John Johansen wrote:
>> sorry I am wayyyy behind on this, so starting from here
>>
>> On 9/6/22 16:24, Paul Moore wrote:
>>> I can't currently in good conscience defend the kernel/userspace
>>> combined label interfaces as "good", especially when we have a very
>>> rare opportunity to do better.
>>>
>>
>> so I am going to grab and hold onto
>>>>> Further, I think we can add the new syscall API separately from the
>>>>> LSM stacking changes as they do have standalone value.
>>>>
>>
>> what I think Paul is saying is we can move the LSM stacking patches
>> forward by removing the combined label interface.
> 
> Do you mean /proc/self/attr/interface_lsm? /proc/.../attr/context?

/proc/.../attr/context is the combined label interface.

/proc/self/attr/interface_lsm is an interesting question. Its not
a combined label interface, instead it is a new interface that allows
controlling of which LSM the task get to see on the old
/proc/.../attr/* interface.

Loosing it would hurt (its a useful tool and is currently necessary
for the SElinux host + AppArmor in container use case) but I think
if that is cost to move forward dropping it at least for now would
be worth it.



>> They won't be as
>> useful but it would be a huge step forward, and the next step could
>> be the syscall API.
> 

Re: LSM stacking in next for 6.1?

[Paul Moore]

On Tue, Sep 6, 2022 at 8:10 PM John Johansen
<john.johansen@canonical.com> wrote:
> On 9/6/22 16:24, Paul Moore wrote:
> > On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >> On 9/2/2022 2:30 PM, Paul Moore wrote:
> >>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
> >>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:

...

> > If you are running AppArmor on the host system and SELinux in a
> > container you are likely going to have some *very* bizarre behavior as
> > the SELinux policy you load in the container will apply to the entire
> > system, including processes which started *before* the SELinux policy
> > was loaded.  While I understand the point you are trying to make, I
> > don't believe the example you chose is going to work without a lot of
> > other changes.
>
> correct but the reverse does work ...

Sure, that doesn't surprise me, but that isn't the example Casey brought up.

> >>> I think it's time to think about a proper set of LSM syscalls.
> >>
> >> At the very least we need a liblsm that preforms a number of useful
> >> functions, like identifying what security modules are available,
> >> validating "contexts", fetching "contexts" from files and processes
> >> and that sort of thing. Whether it is built on syscalls or /proc and
> >> getxattr() is a matter of debate and taste.
> >
> > Why is it a forgone conclusion that a library would be necessary for
> > basic operations?  If the kernel/userspace API is sane to begin with
> > we could probably either significantly reduce or eliminate the need
> > for additional libraries.  I really want us to attempt to come up with
> > a decent kernel/userspace API to begin with as opposed to using the
> > excuse of a userspace library to hide API sins that never should have
> > been committed.
>
> I don't think its a foregone conclusion, its just that it has been
> discussed several times, and all the interfaces have been nasty and
> prebaked userspace code would be really nice to have.
>
> There are other reasons to use a lib as well. Libs can help apps
> pickup fixes/changes automatically.

Fair point.

> > The LSM stacking work presents us with a unique opportunity to
> > modify/update/whatever the LSM kernel/userspace API, I don't want to
> > see us squander this chance on a hack.
>
> I do wish we had a better API from the beginning. I just hope it isn't
> going to take another 10 years to get the API portion done.

This really should surprise no one at this point, but I care very
little about how long something might take, or how difficult it might
be if it is something we are going to have to live with
<dramatic_voice>forever</dramatic_voice>.  I'm sympathetic that this
work has been going on for some time, but that is no reason to push
through a bad design; look at the ACKs/reviews on the combined-label
patches vs the others in the series, that's a pretty good indication
that no one is really excited about that design.

> >> The /proc interfaces interface_lsm and context are really pretty simple.
>
> > They are now, they are also a bit of a mess with legacy constraints
> > and they only get more complicated and messy with the LSM stacking
> > patches.  It is my opinion that a syscall-based API is cleaner and
> > easier for applications to use.
>
> potentially if we can get one

Let me try and remove some ambiguity from that - I'm not going to
merge any combined-label APIs.  I'm not sold on the syscall-based API,
I'm open to other ideas, but it needs to support distinct per-LSM
labels that allow applications to identify which LSMs are active and
which labels belong to each.  In addition, I do not want any changes
to the existing procfs APIs as I want there to be zero chance we will
break existing applications; if existing applications need to be made
aware of a simul-multi-LSM world then they would need to change to the
new API, whatever that may be.

> >>> Further, I think we can add the new syscall API separately from the
> >>> LSM stacking changes as they do have standalone value.
>
> what I think Paul is saying is we can move the LSM stacking patches
> forward by removing the combined label interface. They won't be as
> useful but it would be a huge step forward, and the next step could
> be the syscall API.

Whatever new LSM API we decide on, I want to see that developed and
merged first.  It obviously must be designed to support multiple,
simultaneously active LSMs.

-- 
paul-moore.com

Re: LSM stacking in next for 6.1?

[Casey Schaufler]

On 9/7/2022 7:41 AM, Paul Moore wrote:
> On Tue, Sep 6, 2022 at 8:10 PM John Johansen
> <john.johansen@canonical.com> wrote:
>> On 9/6/22 16:24, Paul Moore wrote:
>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> ..
>
>>> If you are running AppArmor on the host system and SELinux in a
>>> container you are likely going to have some *very* bizarre behavior as
>>> the SELinux policy you load in the container will apply to the entire
>>> system, including processes which started *before* the SELinux policy
>>> was loaded.  While I understand the point you are trying to make, I
>>> don't believe the example you chose is going to work without a lot of
>>> other changes.
>> correct but the reverse does work ...
> Sure, that doesn't surprise me, but that isn't the example Casey brought up.

I said that I'm not sure how they go about doing Android on Ubuntu.
I brought it up because I've seen it.


>>>>> I think it's time to think about a proper set of LSM syscalls.
>>>> At the very least we need a liblsm that preforms a number of useful
>>>> functions, like identifying what security modules are available,
>>>> validating "contexts", fetching "contexts" from files and processes
>>>> and that sort of thing. Whether it is built on syscalls or /proc and
>>>> getxattr() is a matter of debate and taste.
>>> Why is it a forgone conclusion that a library would be necessary for
>>> basic operations?  If the kernel/userspace API is sane to begin with
>>> we could probably either significantly reduce or eliminate the need
>>> for additional libraries.  I really want us to attempt to come up with
>>> a decent kernel/userspace API to begin with as opposed to using the
>>> excuse of a userspace library to hide API sins that never should have
>>> been committed.
>> I don't think its a foregone conclusion, its just that it has been
>> discussed several times, and all the interfaces have been nasty and
>> prebaked userspace code would be really nice to have.
>>
>> There are other reasons to use a lib as well. Libs can help apps
>> pickup fixes/changes automatically.
> Fair point.
>
>>> The LSM stacking work presents us with a unique opportunity to
>>> modify/update/whatever the LSM kernel/userspace API, I don't want to
>>> see us squander this chance on a hack.
>> I do wish we had a better API from the beginning. I just hope it isn't
>> going to take another 10 years to get the API portion done.
> This really should surprise no one at this point, but I care very
> little about how long something might take, or how difficult it might
> be if it is something we are going to have to live with
> <dramatic_voice>forever</dramatic_voice>.

Fair point.

>   I'm sympathetic that this
> work has been going on for some time, but that is no reason to push
> through a bad design; look at the ACKs/reviews on the combined-label
> patches vs the others in the series, that's a pretty good indication
> that no one is really excited about that design.

The kernel developers aren't the consumers of these APIs. There
has been considerable feedback from system application developers
on the interfaces. This included dbus and systemd. Kernel developers
aren't interested in these APIs because they don't care one way or
the other. That, and as you are painfully aware, some of them are
really busy on their own projects.

Am I really happy with the "hideous" format? Yeah, because it makes
the end user happy. Am I happy with interface_lsm? Other than the
name, which was the result of feedback, yes, because it in the
simplest way to accomplish the goal.

I am curious about what you think is "bad" about the current design.
The interfaces aren't exciting. They don't need to be.

>>>> The /proc interfaces interface_lsm and context are really pretty simple.
>>> They are now, they are also a bit of a mess with legacy constraints
>>> and they only get more complicated and messy with the LSM stacking
>>> patches.  It is my opinion that a syscall-based API is cleaner and
>>> easier for applications to use.
>> potentially if we can get one
> Let me try and remove some ambiguity from that - I'm not going to
> merge any combined-label APIs.

Why? A combined-label API is what the application developers asked for.

>   I'm not sold on the syscall-based API,
> I'm open to other ideas, but it needs to support distinct per-LSM
> labels that allow applications to identify which LSMs are active and
> which labels belong to each.

??????? This is exactly what I've provided.

	"apparmor\0unconfined\0smack\0User\0"

You know exactly what LSMs are providing data and what that data is.
How could it be clearer or cleaner?

>   In addition, I do not want any changes
> to the existing procfs APIs as I want there to be zero chance we will
> break existing applications;

Are you saying that interface_lsm changes the /proc/.../attr/current API?
That API is already dependent on the active security module. You may get
an AppArmor, SELinux or Smack context from that API. It's been thus for a
long time. Creating the smack and apparmor subdirectories was done to help
make this cleaner. But those are new APIs. The existing applications either
allow for a variety of security modules (e.g. ps(1)) or need to check for
a particular one (e.g. id(1), which doesn't need to and would be better if
it didn't, but what the hay). If they don't they are flawed and should be
repaired.

>  if existing applications need to be made
> aware of a simul-multi-LSM world then they would need to change to the
> new API, whatever that may be.

Agreed. That's why the proposed APIs have been discussed with many
of those application communities.

>>>>> Further, I think we can add the new syscall API separately from the
>>>>> LSM stacking changes as they do have standalone value.
>> what I think Paul is saying is we can move the LSM stacking patches
>> forward by removing the combined label interface. They won't be as
>> useful but it would be a huge step forward, and the next step could
>> be the syscall API.
> Whatever new LSM API we decide on, I want to see that developed and
> merged first.  It obviously must be designed to support multiple,
> simultaneously active LSMs.

That's what I've been proposing all along. You don't like the APIs.
What don't you like about them? I believe they address the objections
you've raised. I know that I can be real obtuse from time to time,
but I don't see how they fail to meet your requirements.

Re: LSM stacking in next for 6.1?

[John Johansen]

On 9/7/22 09:41, Casey Schaufler wrote:
> On 9/7/2022 7:41 AM, Paul Moore wrote:
>> On Tue, Sep 6, 2022 at 8:10 PM John Johansen
>> <john.johansen@canonical.com> wrote:
>>> On 9/6/22 16:24, Paul Moore wrote:
>>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> ..
>>
>>>> If you are running AppArmor on the host system and SELinux in a
>>>> container you are likely going to have some *very* bizarre behavior as
>>>> the SELinux policy you load in the container will apply to the entire
>>>> system, including processes which started *before* the SELinux policy
>>>> was loaded.  While I understand the point you are trying to make, I
>>>> don't believe the example you chose is going to work without a lot of
>>>> other changes.
>>> correct but the reverse does work ...
>> Sure, that doesn't surprise me, but that isn't the example Casey brought up.
> 
> I said that I'm not sure how they go about doing Android on Ubuntu.
> I brought it up because I've seen it.
> 

LSM stacking for that use case is necessary but insufficient. At a minimum
SELinux would need bounding, and realistically some other gymnastics. I
don't hold out hope of it happening soon if ever. I have told the anbox people
such. At the momement anbox disables SELinux when run in a container

https://github.com/anbox/platform_system_core/commit/71907fc5e7833866be6ae3c120c602974edf8322

there has been work on using a VM instead so that they can have SELinux
but I am not current on how/when that is used.

Where Canonical is interested in LSM stacking is running snaps with apparmor
confinement on top of SELinux distros. I know snaps aren't popular but it is
a much more realistic and attainable use case for LSM stacking.

Re: LSM stacking in next for 6.1?

[Paul Moore]

On Wed, Sep 7, 2022 at 1:23 PM John Johansen
<john.johansen@canonical.com> wrote:
> On 9/7/22 09:41, Casey Schaufler wrote:
> > On 9/7/2022 7:41 AM, Paul Moore wrote:
> >> On Tue, Sep 6, 2022 at 8:10 PM John Johansen
> >> <john.johansen@canonical.com> wrote:
> >>> On 9/6/22 16:24, Paul Moore wrote:
> >>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >>>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
> >>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
> >>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >> ..
> >>
> >>>> If you are running AppArmor on the host system and SELinux in a
> >>>> container you are likely going to have some *very* bizarre behavior as
> >>>> the SELinux policy you load in the container will apply to the entire
> >>>> system, including processes which started *before* the SELinux policy
> >>>> was loaded.  While I understand the point you are trying to make, I
> >>>> don't believe the example you chose is going to work without a lot of
> >>>> other changes.
> >>> correct but the reverse does work ...
> >> Sure, that doesn't surprise me, but that isn't the example Casey brought up.
> >
> > I said that I'm not sure how they go about doing Android on Ubuntu.
> > I brought it up because I've seen it.
>
> LSM stacking for that use case is necessary but insufficient.

Yes, exactly.  One of my bigger worries about the stacking effort is
that a lot of people have some false assumptions about what it will
actually enable.  Of course that doesn't mean it isn't worth doing,
just that there may be a lot of disappointed people out there.

> At a minimum
> SELinux would need bounding, and realistically some other gymnastics. I
> don't hold out hope of it happening soon if ever. I have told the anbox people
> such.

Most of that is just a matter of writing the code.  Yes, that's going
to be a decent chunk of work, but the idea is relatively
straightforward.  The bit that keeps blocking this in my mind is
handling of the persistent filesystem labels, that's a conceptual
problem we have yet to solve.  The current solution of just creating
more and more (scoped) xattrs isn't going to scale to the level I
believe we are going to need.  I keep toying with the idea of just
punting on it and leaving it up to the container orchestrator to
manage the filesystems; if you want to run a nested SELinux instance
inside a container with dedicated file labels you need your own
filesystem mounted.  Dunno, lots to think about here ...

> At the momement anbox disables SELinux when run in a container
>
> https://github.com/anbox/platform_system_core/commit/71907fc5e7833866be6ae3c120c602974edf8322
>
> there has been work on using a VM instead so that they can have SELinux
> but I am not current on how/when that is used.

That makes much more sense, thanks John.

-- 
paul-moore.com

Re: LSM stacking in next for 6.1?

[Paul Moore]

On Wed, Sep 7, 2022 at 12:42 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 9/7/2022 7:41 AM, Paul Moore wrote:
> > On Tue, Sep 6, 2022 at 8:10 PM John Johansen
> > <john.johansen@canonical.com> wrote:
> >> On 9/6/22 16:24, Paul Moore wrote:
> >>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
> >>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
> >>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> > ..
> >
> >>> If you are running AppArmor on the host system and SELinux in a
> >>> container you are likely going to have some *very* bizarre behavior as
> >>> the SELinux policy you load in the container will apply to the entire
> >>> system, including processes which started *before* the SELinux policy
> >>> was loaded.  While I understand the point you are trying to make, I
> >>> don't believe the example you chose is going to work without a lot of
> >>> other changes.
> >> correct but the reverse does work ...
> > Sure, that doesn't surprise me, but that isn't the example Casey brought up.
>
> I said that I'm not sure how they go about doing Android on Ubuntu.
> I brought it up because I've seen it.

Addressed in the other portion of this thread, but the quick response
here is: No, you were mistaken, that was not proper Android, SELinux
was disabled.

> > I'm sympathetic that this
> > work has been going on for some time, but that is no reason to push
> > through a bad design; look at the ACKs/reviews on the combined-label
> > patches vs the others in the series, that's a pretty good indication
> > that no one is really excited about that design.
>
> The kernel developers aren't the consumers of these APIs. There
> has been considerable feedback from system application developers
> on the interfaces. This included dbus and systemd. Kernel developers
> aren't interested in these APIs because they don't care one way or
> the other. That, and as you are painfully aware, some of them are
> really busy on their own projects.

Yes, everyone is busy yet they found time to ACK/review the other
patches in the patchset.  I'm not buying the "busy" argument here.

Yes, you are also correct in that the kernel devs are not likely to be
the main consumers of any kernel/userspace API, but we do have to
support these APIs and find ways to handle the inevitable misuse and
abuse of these APIs.  Further, while I do believe that you've talked
to some application developers about the current proposed API, I'm
reasonably confident that it isn't the only API they would be happy
supporting in their applications.

As far as kernel developers not being interested in these APIs, I
think the recent conversation in this thread proves the exact opposite
;)

> Am I really happy with the "hideous" format? Yeah, because it makes
> the end user happy. Am I happy with interface_lsm? Other than the
> name, which was the result of feedback, yes, because it in the
> simplest way to accomplish the goal.
>
> I am curious about what you think is "bad" about the current design.
> The interfaces aren't exciting. They don't need to be.

I don't even know what an exciting interface would look like ... ?  I
just want an interface that is clearly defined, has reasonable
capacity to be extended in the future as needed, and is easy(ish) to
use and support over extended periods of time (both from a kernel and
userspace perspective).

The "smack_label\0apparmor_label\0selinux_label\0future_lsm_label\0"
string interface is none of these things.  It is not clearly defined
as it requires other interfaces to associate the labels with the
correct LSMs.  It has no provision for extension beyond adding a new
LSM.  The ease-of-use quality is a bit subjective, but it does need
another interface to use properly and it requires string parsing which
history has shown to be an issue time and time again (although it is
relatively simple here).

Once again, the syscall example I tossed out was a quick strawman, but
it had clearly separated and defined labels conveyed in data
structures that didn't require string parsing to find the label
associated with an LSM.  It was also self-contained in that no other
interface was needed to interpret the results of the syscall (well,
beyond the header file definitions I guess).  Finally, it made use of
flags and "reserved for future use" token values to allow for
additional data to be conveyed in the future.

-- 
paul-moore.com

Re: LSM stacking in next for 6.1?

[Casey Schaufler]

On 9/7/2022 4:27 PM, Paul Moore wrote:
> On Wed, Sep 7, 2022 at 12:42 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/7/2022 7:41 AM, Paul Moore wrote:
>>> On Tue, Sep 6, 2022 at 8:10 PM John Johansen
>>> <john.johansen@canonical.com> wrote:
>>>> On 9/6/22 16:24, Paul Moore wrote:
>>>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>> ..
>>>
>>>>> If you are running AppArmor on the host system and SELinux in a
>>>>> container you are likely going to have some *very* bizarre behavior as
>>>>> the SELinux policy you load in the container will apply to the entire
>>>>> system, including processes which started *before* the SELinux policy
>>>>> was loaded.  While I understand the point you are trying to make, I
>>>>> don't believe the example you chose is going to work without a lot of
>>>>> other changes.
>>>> correct but the reverse does work ...
>>> Sure, that doesn't surprise me, but that isn't the example Casey brought up.
>> I said that I'm not sure how they go about doing Android on Ubuntu.
>> I brought it up because I've seen it.
> Addressed in the other portion of this thread, but the quick response
> here is: No, you were mistaken, that was not proper Android, SELinux
> was disabled.
>
>>> I'm sympathetic that this
>>> work has been going on for some time, but that is no reason to push
>>> through a bad design; look at the ACKs/reviews on the combined-label
>>> patches vs the others in the series, that's a pretty good indication
>>> that no one is really excited about that design.
>> The kernel developers aren't the consumers of these APIs. There
>> has been considerable feedback from system application developers
>> on the interfaces. This included dbus and systemd. Kernel developers
>> aren't interested in these APIs because they don't care one way or
>> the other. That, and as you are painfully aware, some of them are
>> really busy on their own projects.
> Yes, everyone is busy yet they found time to ACK/review the other
> patches in the patchset.  I'm not buying the "busy" argument here.
>
> Yes, you are also correct in that the kernel devs are not likely to be
> the main consumers of any kernel/userspace API, but we do have to
> support these APIs and find ways to handle the inevitable misuse and
> abuse of these APIs.  Further, while I do believe that you've talked
> to some application developers about the current proposed API, I'm
> reasonably confident that it isn't the only API they would be happy
> supporting in their applications.
>
> As far as kernel developers not being interested in these APIs, I
> think the recent conversation in this thread proves the exact opposite
> ;)
>
>> Am I really happy with the "hideous" format? Yeah, because it makes
>> the end user happy. Am I happy with interface_lsm? Other than the
>> name, which was the result of feedback, yes, because it in the
>> simplest way to accomplish the goal.
>>
>> I am curious about what you think is "bad" about the current design.
>> The interfaces aren't exciting. They don't need to be.
> I don't even know what an exciting interface would look like ... ?

io_uring? :)

>   I
> just want an interface that is clearly defined, has reasonable
> capacity to be extended in the future as needed, and is easy(ish) to
> use and support over extended periods of time (both from a kernel and
> userspace perspective).
>
> The "smack_label\0apparmor_label\0selinux_label\0future_lsm_label\0"
> string interface is none of these things.

In this we disagree ....

>   It is not clearly defined
> as it requires other interfaces to associate the labels with the
> correct LSMs.

The label follows the lsm name directly. What other association is required?

>   It has no provision for extension beyond adding a new
> LSM.

I grant that. But the purpose of the format is to present LSM/context
pairs. What other information would make sense? We could add an "aux"
field, but that seems somewhat arbitrary.

>   The ease-of-use quality is a bit subjective, but it does need
> another interface to use properly and it requires string parsing which
> history has shown to be an issue time and time again (although it is
> relatively simple here).

There was a lot of discussion regarding that. My proposed
apparmor="unconfined",smack="User" format was panned for those same reasons.
The nil byte format has been used elsewhere and suggested for that reason.

>
> Once again, the syscall example I tossed out was a quick strawman, but
> it had clearly separated and defined labels conveyed in data
> structures that didn't require string parsing to find the label
> associated with an LSM.

True, but it uses pointers internally and you can't do that in memory
you're sending up from the system. What comes from the syscall has to
look something like the nil byte format. The strawman would have to do
the same sort of parsing in userspace that you are objecting to.

>   It was also self-contained in that no other
> interface was needed to interpret the results of the syscall (well,
> beyond the header file definitions I guess).  Finally, it made use of
> flags and "reserved for future use" token values to allow for
> additional data to be conveyed in the future.

Can you describe potential flags or additional data? Planning for the future
is a good idea, but throwing fields on "just in case" seems contrary to
what I'm used to hearing from you.

Re: LSM stacking in next for 6.1?

[John Johansen]

On 9/7/22 16:53, Casey Schaufler wrote:
> On 9/7/2022 4:27 PM, Paul Moore wrote:
>> On Wed, Sep 7, 2022 at 12:42 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>> On 9/7/2022 7:41 AM, Paul Moore wrote:
>>>> On Tue, Sep 6, 2022 at 8:10 PM John Johansen
>>>> <john.johansen@canonical.com> wrote:
>>>>> On 9/6/22 16:24, Paul Moore wrote:
>>>>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>>>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>> ..
>>>>
>>>>>> If you are running AppArmor on the host system and SELinux in a
>>>>>> container you are likely going to have some *very* bizarre behavior as
>>>>>> the SELinux policy you load in the container will apply to the entire
>>>>>> system, including processes which started *before* the SELinux policy
>>>>>> was loaded.  While I understand the point you are trying to make, I
>>>>>> don't believe the example you chose is going to work without a lot of
>>>>>> other changes.
>>>>> correct but the reverse does work ...
>>>> Sure, that doesn't surprise me, but that isn't the example Casey brought up.
>>> I said that I'm not sure how they go about doing Android on Ubuntu.
>>> I brought it up because I've seen it.
>> Addressed in the other portion of this thread, but the quick response
>> here is: No, you were mistaken, that was not proper Android, SELinux
>> was disabled.
>>
>>>> I'm sympathetic that this
>>>> work has been going on for some time, but that is no reason to push
>>>> through a bad design; look at the ACKs/reviews on the combined-label
>>>> patches vs the others in the series, that's a pretty good indication
>>>> that no one is really excited about that design.
>>> The kernel developers aren't the consumers of these APIs. There
>>> has been considerable feedback from system application developers
>>> on the interfaces. This included dbus and systemd. Kernel developers
>>> aren't interested in these APIs because they don't care one way or
>>> the other. That, and as you are painfully aware, some of them are
>>> really busy on their own projects.
>> Yes, everyone is busy yet they found time to ACK/review the other
>> patches in the patchset.  I'm not buying the "busy" argument here.
>>
>> Yes, you are also correct in that the kernel devs are not likely to be
>> the main consumers of any kernel/userspace API, but we do have to
>> support these APIs and find ways to handle the inevitable misuse and
>> abuse of these APIs.  Further, while I do believe that you've talked
>> to some application developers about the current proposed API, I'm
>> reasonably confident that it isn't the only API they would be happy
>> supporting in their applications.
>>
>> As far as kernel developers not being interested in these APIs, I
>> think the recent conversation in this thread proves the exact opposite
>> ;)
>>
>>> Am I really happy with the "hideous" format? Yeah, because it makes
>>> the end user happy. Am I happy with interface_lsm? Other than the
>>> name, which was the result of feedback, yes, because it in the
>>> simplest way to accomplish the goal.
>>>
>>> I am curious about what you think is "bad" about the current design.
>>> The interfaces aren't exciting. They don't need to be.
>> I don't even know what an exciting interface would look like ... ?
> 
> io_uring? :)
> 
>>    I
>> just want an interface that is clearly defined, has reasonable
>> capacity to be extended in the future as needed, and is easy(ish) to
>> use and support over extended periods of time (both from a kernel and
>> userspace perspective).
>>
>> The "smack_label\0apparmor_label\0selinux_label\0future_lsm_label\0"
>> string interface is none of these things.
> 
> In this we disagree ....
> 
>>    It is not clearly defined
>> as it requires other interfaces to associate the labels with the
>> correct LSMs.
> 
> The label follows the lsm name directly. What other association is required?
> 
its a serialized message format, with all the data in the message
instead of pointer to external memory. If you want nicer to handle
you wrap a lib around it, this is pretty common. That is why I don't
see it as that different from the syscall.

>>    It has no provision for extension beyond adding a new
>> LSM.
> 
> I grant that. But the purpose of the format is to present LSM/context
> pairs. What other information would make sense? We could add an "aux"
> field, but that seems somewhat arbitrary.
> 
or you know a header that gives potential future, also potentially a
count, ...

>>    The ease-of-use quality is a bit subjective, but it does need
>> another interface to use properly and it requires string parsing which
>> history has shown to be an issue time and time again (although it is
>> relatively simple here).
> 
> There was a lot of discussion regarding that. My proposed
> apparmor="unconfined",smack="User" format was panned for those same reasons.
> The nil byte format has been used elsewhere and suggested for that reason.
> 

At this level the lib provides the ease of use, but I think that is
what we are going to need with a syscall too, as marshalling variable
number/length data is always somewhat ugly.

>>
>> Once again, the syscall example I tossed out was a quick strawman, but
>> it had clearly separated and defined labels conveyed in data
>> structures that didn't require string parsing to find the label
>> associated with an LSM.
> 
> True, but it uses pointers internally and you can't do that in memory
> you're sending up from the system. What comes from the syscall has to

Well you can, see the mess that is ioctl. The point being those internal
pointers are going to have to be mapped/copied and doing that is a mess
as well. Either way you want a common set of code to handle it. The
advantage of the syscall, from a userspace perspective, is that all the
code to handle the mapping is in the kernel.

The problem from kernel perspective is that multiple copies to/from
userspace have races. You have to make sure you have marshalled/setup
all the data before you can do anything with it.

> look something like the nil byte format. The strawman would have to do
> the same sort of parsing in userspace that you are objecting to.
> 
Not necessarily the nil byte format, but yeah it all has to be setup
nicely in advance.

>>    It was also self-contained in that no other
>> interface was needed to interpret the results of the syscall (well,
>> beyond the header file definitions I guess).  Finally, it made use of
>> flags and "reserved for future use" token values to allow for
>> additional data to be conveyed in the future.
> 
> Can you describe potential flags or additional data? Planning for the future
> is a good idea, but throwing fields on "just in case" seems contrary to
> what I'm used to hearing from you.
> 

Well a few potential ones I can think of
version - providing future flexibility
count - for how many lsm entries to expect
size - I don't think its really necessary here but in a message format it is
        usually good to have a size of message value.
kind - some flags indicating the type of data. Eg. LSM name, LSM context pair
table - not necessary unless we want to get rid of the \0 separator so
         that \0 could be allowed as value within the data, an index into
         the message for each LSMs
         data.

At this point I don't really care if its a syscall or a serialized message.
I see them as roughly equivalent, its just a matter of where you are going to
put the ugly.

Re: LSM stacking in next for 6.1?

[Paul Moore]

On Wed, Sep 7, 2022 at 7:53 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 9/7/2022 4:27 PM, Paul Moore wrote:

...

> >   I
> > just want an interface that is clearly defined, has reasonable
> > capacity to be extended in the future as needed, and is easy(ish) to
> > use and support over extended periods of time (both from a kernel and
> > userspace perspective).
> >
> > The "smack_label\0apparmor_label\0selinux_label\0future_lsm_label\0"
> > string interface is none of these things.
>
> In this we disagree ....

I think we can both agree that there is a subjective aspect to this
argument and it may be that we never reach agreement on the "best"
approach, if there even is such a thing.  What I am trying to do here
is describe a path that would allow me to be more comfortable merging
the LSM stacking functionality; I don't think you've had a clearly
defined path, of any sort, towards getting these patches merged, which
is a problem and I suspect the source of some of the frustration.  My
comments, as objectionable as you may find them to be, are intended to
help you move forward with these patches.

> >   It is not clearly defined
> > as it requires other interfaces to associate the labels with the
> > correct LSMs.
>
> The label follows the lsm name directly. What other association is required?

You need to know the order of the LSMs in order to
interpret/de-serialize the string.

> >   The ease-of-use quality is a bit subjective, but it does need
> > another interface to use properly and it requires string parsing which
> > history has shown to be an issue time and time again (although it is
> > relatively simple here).
>
> There was a lot of discussion regarding that. My proposed
> apparmor="unconfined",smack="User" format was panned for those same reasons.
> The nil byte format has been used elsewhere and suggested for that reason.

Based on what I recall from those discussions, it was my impression
the nil byte label delimiter was suggested simply because no one was
entertaining the idea of using something other than the existing
procfs interface.  It is my opinion that we've taken that interface
about as far as it can go, and while it needs to stay intact for
compatibility reasons, the LSM stacking functionality should move to a
different API that is better suited for it.

> > Once again, the syscall example I tossed out was a quick strawman, but
> > it had clearly separated and defined labels conveyed in data
> > structures that didn't require string parsing to find the label
> > associated with an LSM.
>
> True, but it uses pointers internally and you can't do that in memory
> you're sending up from the system. What comes from the syscall has to
> look something like the nil byte format. The strawman would have to do
> the same sort of parsing in userspace that you are objecting to.

Then we change the strawman.  That's pretty much the definition of a
strawman example, it's something you toss out as starting point for
discussion and future improvements.  If it was something much more
fully developed I would have submitted a patch .... sheesh.

In case it helps spur your imagination, here is a revised strawman:

/**
 * struct lsm_ctx - LSM context
 * @id: the LSM id number, see LSM_ID_XXX
 * @flags: LSM specific flags, zero if unused
 * @ctx_len: the size of @ctx
 * @ctx: the LSM context
 */
struct lsm_ctx {
  unsigned in id;
  unsigned int flags;
  size_t ctx_len;
  unsigned char ctx[];
};

/**
 * lsm_current_ctx - Return current tasks's LSM context
 * @ctx: the LSM contexts
 * @size: the size of @ctx, 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 minimum required
 * size 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 *size,
                    unsigned int flags);

> >   It was also self-contained in that no other
> > interface was needed to interpret the results of the syscall (well,
> > beyond the header file definitions I guess).  Finally, it made use of
> > flags and "reserved for future use" token values to allow for
> > additional data to be conveyed in the future.
>
> Can you describe potential flags or additional data? Planning for the future
> is a good idea, but throwing fields on "just in case" seems contrary to
> what I'm used to hearing from you.

Adding flags to a syscall is a fairly common practice.  If you're
making the mistake of confusing this with the discussion that is
ongoing audit/fanotify discussion, you can think of the flags as
similar to adding a type/length field to a struct (which I support).

-- 
paul-moore.com

Re: LSM stacking in next for 6.1?

[Casey Schaufler]

On 9/7/2022 8:57 PM, Paul Moore wrote:
> On Wed, Sep 7, 2022 at 7:53 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/7/2022 4:27 PM, Paul Moore wrote:
> ..
>
>>>   I
>>> just want an interface that is clearly defined, has reasonable
>>> capacity to be extended in the future as needed, and is easy(ish) to
>>> use and support over extended periods of time (both from a kernel and
>>> userspace perspective).
>>>
>>> The "smack_label\0apparmor_label\0selinux_label\0future_lsm_label\0"
>>> string interface is none of these things.

That wasn't the proposal. The proposal was

"smack\0smack_label\0apparmor\0apparmor_label\0future_lsm\0future_lsm_label\0"

>> In this we disagree ....
> I think we can both agree that there is a subjective aspect to this
> argument and it may be that we never reach agreement on the "best"
> approach, if there even is such a thing.  What I am trying to do here
> is describe a path that would allow me to be more comfortable merging
> the LSM stacking functionality; I don't think you've had a clearly
> defined path, of any sort, towards getting these patches merged, which
> is a problem and I suspect the source of some of the frustration.  My
> comments, as objectionable as you may find them to be, are intended to
> help you move forward with these patches.

OK. Let's get'er done.

>>>   It is not clearly defined
>>> as it requires other interfaces to associate the labels with the
>>> correct LSMs.
>> The label follows the lsm name directly. What other association is required?
> You need to know the order of the LSMs in order to
> interpret/de-serialize the string.

That's true for the string you included, but not for what I had
actually proposed.

>>>   The ease-of-use quality is a bit subjective, but it does need
>>> another interface to use properly and it requires string parsing which
>>> history has shown to be an issue time and time again (although it is
>>> relatively simple here).
>> There was a lot of discussion regarding that. My proposed
>> apparmor="unconfined",smack="User" format was panned for those same reasons.
>> The nil byte format has been used elsewhere and suggested for that reason.
> Based on what I recall from those discussions, it was my impression
> the nil byte label delimiter was suggested simply because no one was
> entertaining the idea of using something other than the existing
> procfs interface.  It is my opinion that we've taken that interface
> about as far as it can go, and while it needs to stay intact for
> compatibility reasons, the LSM stacking functionality should move to a
> different API that is better suited for it.

It's going to raise its ugly head again with SO_PEERCONTEXT for the
SELinux+Smack case. But we can cross that bridge when we come to it.

>>> Once again, the syscall example I tossed out was a quick strawman, but
>>> it had clearly separated and defined labels conveyed in data
>>> structures that didn't require string parsing to find the label
>>> associated with an LSM.
>> True, but it uses pointers internally and you can't do that in memory
>> you're sending up from the system. What comes from the syscall has to
>> look something like the nil byte format. The strawman would have to do
>> the same sort of parsing in userspace that you are objecting to.
> Then we change the strawman.  That's pretty much the definition of a
> strawman example, it's something you toss out as starting point for
> discussion and future improvements.  If it was something much more
> fully developed I would have submitted a patch .... sheesh.

Fair enough.

> In case it helps spur your imagination, here is a revised strawman:
>
> /**
>  * struct lsm_ctx - LSM context
>  * @id: the LSM id number, see LSM_ID_XXX

A LSM ID hard coded in a kernel header makes it harder to develop new
security modules. The security module can't be self contained. I say
that, but I acknowledge that I've done the same kind of thing with the
definition of the struct lsmblob. That isn't part of an external API
however. It may also interfere with Tetsuo's long standing request that
we don't do things that prevent the possibility of loadable security
modules at some point in the future. I will also mention the out-of-tree
security module objection, not because I care, but because someone most
likely will bring it up.

On the other hand, there's no great way to include two variable length
strings in a structure like this. So unless we adopt something as ugly
as the nil byte scheme this is supposed to replace I expect we're stuck
with an LSM ID.

>  
>  * @flags: LSM specific flags, zero if unused

For an API shouldn't this be a specific size? u32? I'm not really
up to date on the guidance regarding which it should be.

>  * @ctx_len: the size of @ctx
>  * @ctx: the LSM context
>  */
> struct lsm_ctx {
>   unsigned in id;
>   unsigned int flags;
>   size_t ctx_len;
>   unsigned char ctx[];
> };
>
> /**
>  * lsm_current_ctx - Return current tasks's LSM context
>  * @ctx: the LSM contexts
>  * @size: the size of @ctx, 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 minimum required
>  * size is returned via @count.  In all other failure cases, a

s/count/size/ - but I get what you meant.

>  * negative value indicating the error is returned.
>  */
> int lsm_current_ctx(struct lsm_ctx *ctx, size_t *size,
>                     unsigned int flags);

This is a workable interface. Certainly more friendly than the
nil byte format.

>   It was also self-contained in that no other
> interface was needed to interpret the results of the syscall (well,
> beyond the header file definitions I guess).  Finally, it made use of
> flags and "reserved for future use" token values to allow for
> additional data to be conveyed in the future.
>> Can you describe potential flags or additional data? Planning for the future
>> is a good idea, but throwing fields on "just in case" seems contrary to
>> what I'm used to hearing from you.
> Adding flags to a syscall is a fairly common practice.  If you're
> making the mistake of confusing this with the discussion that is
> ongoing audit/fanotify discussion, you can think of the flags as
> similar to adding a type/length field to a struct (which I support).

OK. I can see potential.

I will head in this direction. A couple questions:

Would we want lsm_prev_ctx() as well as lsm_current_ctx(),
or should we use the lsm_ctx->flags to identify the provided
context? If we did that we should have an lsm_ctx() system call
that returns the current, prev, and whatever other security
module specific attributes might be associated with the process,
each identified in the flags field. While the "current" context
is usually what we're after, there may be cases where the other
attributes are desired.
 

Re: LSM stacking in next for 6.1?

[John Johansen]

On 9/8/22 11:05, Casey Schaufler wrote:
> On 9/7/2022 8:57 PM, Paul Moore wrote:
>> On Wed, Sep 7, 2022 at 7:53 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>> On 9/7/2022 4:27 PM, Paul Moore wrote:
>> ..
>>
>>>>    I
>>>> just want an interface that is clearly defined, has reasonable
>>>> capacity to be extended in the future as needed, and is easy(ish) to
>>>> use and support over extended periods of time (both from a kernel and
>>>> userspace perspective).
>>>>
>>>> The "smack_label\0apparmor_label\0selinux_label\0future_lsm_label\0"
>>>> string interface is none of these things.
> 
> That wasn't the proposal. The proposal was
> 
> "smack\0smack_label\0apparmor\0apparmor_label\0future_lsm\0future_lsm_label\0"
> 
>>> In this we disagree ....
>> I think we can both agree that there is a subjective aspect to this
>> argument and it may be that we never reach agreement on the "best"
>> approach, if there even is such a thing.  What I am trying to do here
>> is describe a path that would allow me to be more comfortable merging
>> the LSM stacking functionality; I don't think you've had a clearly
>> defined path, of any sort, towards getting these patches merged, which
>> is a problem and I suspect the source of some of the frustration.  My
>> comments, as objectionable as you may find them to be, are intended to
>> help you move forward with these patches.
> 
> OK. Let's get'er done.
> 
>>>>    It is not clearly defined
>>>> as it requires other interfaces to associate the labels with the
>>>> correct LSMs.
>>> The label follows the lsm name directly. What other association is required?
>> You need to know the order of the LSMs in order to
>> interpret/de-serialize the string.
> 
> That's true for the string you included, but not for what I had
> actually proposed.
> 
>>>>    The ease-of-use quality is a bit subjective, but it does need
>>>> another interface to use properly and it requires string parsing which
>>>> history has shown to be an issue time and time again (although it is
>>>> relatively simple here).
>>> There was a lot of discussion regarding that. My proposed
>>> apparmor="unconfined",smack="User" format was panned for those same reasons.
>>> The nil byte format has been used elsewhere and suggested for that reason.
>> Based on what I recall from those discussions, it was my impression
>> the nil byte label delimiter was suggested simply because no one was
>> entertaining the idea of using something other than the existing
>> procfs interface.  It is my opinion that we've taken that interface
>> about as far as it can go, and while it needs to stay intact for
>> compatibility reasons, the LSM stacking functionality should move to a
>> different API that is better suited for it.
> 
> It's going to raise its ugly head again with SO_PEERCONTEXT for the
> SELinux+Smack case. But we can cross that bridge when we come to it.
> 

AppArmor too, I am working on revising the out of tree af_unix mediation


>>>> Once again, the syscall example I tossed out was a quick strawman, but
>>>> it had clearly separated and defined labels conveyed in data
>>>> structures that didn't require string parsing to find the label
>>>> associated with an LSM.
>>> True, but it uses pointers internally and you can't do that in memory
>>> you're sending up from the system. What comes from the syscall has to
>>> look something like the nil byte format. The strawman would have to do
>>> the same sort of parsing in userspace that you are objecting to.
>> Then we change the strawman.  That's pretty much the definition of a
>> strawman example, it's something you toss out as starting point for
>> discussion and future improvements.  If it was something much more
>> fully developed I would have submitted a patch .... sheesh.
> 
> Fair enough.
> 
>> In case it helps spur your imagination, here is a revised strawman:
>>
>> /**
>>   * struct lsm_ctx - LSM context
>>   * @id: the LSM id number, see LSM_ID_XXX
> 
> A LSM ID hard coded in a kernel header makes it harder to develop new
> security modules. The security module can't be self contained. I say
> that, but I acknowledge that I've done the same kind of thing with the
> definition of the struct lsmblob. That isn't part of an external API
> however. It may also interfere with Tetsuo's long standing request that
> we don't do things that prevent the possibility of loadable security
> modules at some point in the future. I will also mention the out-of-tree
> security module objection, not because I care, but because someone most
> likely will bring it up.
> 
> On the other hand, there's no great way to include two variable length
> strings in a structure like this. So unless we adopt something as ugly
> as the nil byte scheme this is supposed to replace I expect we're stuck
> with an LSM ID.
> 

well at a minimum we shouldn't export the kernel internal LSM_ID if its
exposed to userspace it needs to be something that can live with for a
long time

- Fixed length strings, which really are just a long LSM ID, Say 8 bytes.
   Can still even look human readable. For most* LSMs this could just
   be their name.

   * only safesetid and capability don't fit atm

- and certainly uglier, for variable length use an index for one of the
   variable length strings, with an embedded \0 inside the variable length
   string

{
   size_t lsm_id_len;
   size_t lsm_id_ctx_index;
   size_t ctx_len;
   unsigned char ctx[];
}

with access to lsm id being ctx[lsm_id_ctx_index]

Re: LSM stacking in next for 6.1?

[Paul Moore]

On Thu, Sep 8, 2022 at 2:05 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 9/7/2022 8:57 PM, Paul Moore wrote:
> > On Wed, Sep 7, 2022 at 7:53 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >> On 9/7/2022 4:27 PM, Paul Moore wrote:

...

> >>>   The ease-of-use quality is a bit subjective, but it does need
> >>> another interface to use properly and it requires string parsing which
> >>> history has shown to be an issue time and time again (although it is
> >>> relatively simple here).
> >> There was a lot of discussion regarding that. My proposed
> >> apparmor="unconfined",smack="User" format was panned for those same reasons.
> >> The nil byte format has been used elsewhere and suggested for that reason.
> > Based on what I recall from those discussions, it was my impression
> > the nil byte label delimiter was suggested simply because no one was
> > entertaining the idea of using something other than the existing
> > procfs interface.  It is my opinion that we've taken that interface
> > about as far as it can go, and while it needs to stay intact for
> > compatibility reasons, the LSM stacking functionality should move to a
> > different API that is better suited for it.
>
> It's going to raise its ugly head again with SO_PEERCONTEXT for the
> SELinux+Smack case. But we can cross that bridge when we come to it.

There are also problems with IP_PASSSEC/SCM_SECURITY that we've never
fully resolved (and have gotten a bit lucky over the years); it very
well could be time to add support for IP_SECURITY as the multi-LSM
replacement for SCM_SECURITY.  We could leverage the same LSM context
structures as in the other multi-LSM interfaces.  Existing
applications could continue to use SCM_SECURITY; in fact I believe we
could have both SCM_SECURITY and IP_SECURITY in the same message for
maximum compatibility.

https://github.com/SELinuxProject/selinux-kernel/issues/24

For SO_PEERSEC, we should probably just introduce SO_PEERSEC2 or
similar, using the same multi-LSM context structures as the other
interfaces.

> > In case it helps spur your imagination, here is a revised strawman:
> >
> > /**
> >  * struct lsm_ctx - LSM context
> >  * @id: the LSM id number, see LSM_ID_XXX
>
> A LSM ID hard coded in a kernel header makes it harder to develop new
> security modules.

There is so much precedence for defining a token scalar value to
represent a "thing" that I don't know where to begin.  Look at IANA,
there are entire organizations that exist to map "things" to numbers.

If you're objecting to assigning LSMs fixed integer numbers you've got
to give me some very explicit reasons (complete with examples) as to
why that would be a mistake.

> The security module can't be self contained. I say
> that, but I acknowledge that I've done the same kind of thing with the
> definition of the struct lsmblob. That isn't part of an external API
> however.

I'm not following you here.  See my comment above about better examples.

> It may also interfere with Tetsuo's long standing request that
> we don't do things that prevent the possibility of loadable security
> modules at some point in the future.

I already replied to Tetsuo's email, and while this particular point
about LSM ID numbers wasn't directly addressed, my response there
seems to apply equally well here: it's not so much about loadable
LSMs, it's about out-of-tree LSMs.  These are two very different
things, with different solutions.

> On the other hand, there's no great way to include two variable length
> strings in a structure like this. So unless we adopt something as ugly
> as the nil byte scheme this is supposed to replace I expect we're stuck
> with an LSM ID.

I don't like making general comments, but when in doubt, consider me
not-a-fan of string-based identifiers in APIs.  Give me token scalar
values instead.

> >  * @flags: LSM specific flags, zero if unused
>
> For an API shouldn't this be a specific size? u32? I'm not really
> up to date on the guidance regarding which it should be.

Enh, sure, whatever.  You'll remember my initial comment about not
being a syscall stylist; if the discussion has moved to seriously
discussing the syscall prototypes we should likely start a new thread
and bring in the syscall folks ... I vaguely remember there was a
mailing list for syscalls and API changes ...

> I will head in this direction. A couple questions:
>
> Would we want lsm_prev_ctx() as well as lsm_current_ctx(),

I'm not sure I'm following your thinking, what would lsm_prev_ctx() do?

> or should we use the lsm_ctx->flags to identify the provided
> context? If we did that we should have an lsm_ctx() system call
> that returns the current, prev, and whatever other security
> module specific attributes might be associated with the process,
> each identified in the flags field. While the "current" context
> is usually what we're after, there may be cases where the other
> attributes are desired.

I don't understand what you mean by "prev"{ious} attributes.  I'm
thinking of lsm_current_ctx() as a multi-LSM replacement for
/proc/self/attr/current.  If, for example, we wanted something for
/proc/self/attr/exec I imagine we would create lsm_current_exec(), or
something similarly named, with a similar prototype.

Or perhaps we try to stick a bit closer to the procfs naming and go
with lsm_self_cur(...) and lsm_self_exec(...).  All things to discuss.

-- 
paul-moore.com

Re: LSM stacking in next for 6.1?

[Casey Schaufler]

On 9/8/2022 12:32 PM, Paul Moore wrote:
> On Thu, Sep 8, 2022 at 2:05 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/7/2022 8:57 PM, Paul Moore wrote:
>>> On Wed, Sep 7, 2022 at 7:53 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>> On 9/7/2022 4:27 PM, Paul Moore wrote:
> ..
>
>>>>>   The ease-of-use quality is a bit subjective, but it does need
>>>>> another interface to use properly and it requires string parsing which
>>>>> history has shown to be an issue time and time again (although it is
>>>>> relatively simple here).
>>>> There was a lot of discussion regarding that. My proposed
>>>> apparmor="unconfined",smack="User" format was panned for those same reasons.
>>>> The nil byte format has been used elsewhere and suggested for that reason.
>>> Based on what I recall from those discussions, it was my impression
>>> the nil byte label delimiter was suggested simply because no one was
>>> entertaining the idea of using something other than the existing
>>> procfs interface.  It is my opinion that we've taken that interface
>>> about as far as it can go, and while it needs to stay intact for
>>> compatibility reasons, the LSM stacking functionality should move to a
>>> different API that is better suited for it.
>> It's going to raise its ugly head again with SO_PEERCONTEXT for the
>> SELinux+Smack case. But we can cross that bridge when we come to it.
> There are also problems with IP_PASSSEC/SCM_SECURITY that we've never
> fully resolved (and have gotten a bit lucky over the years); it very
> well could be time to add support for IP_SECURITY as the multi-LSM
> replacement for SCM_SECURITY.  We could leverage the same LSM context
> structures as in the other multi-LSM interfaces.  Existing
> applications could continue to use SCM_SECURITY; in fact I believe we
> could have both SCM_SECURITY and IP_SECURITY in the same message for
> maximum compatibility.

Adding IP_SECURITY seems sensible. Having both at the same time leaves
us with the question of which security module's value to put in SCM_SECURITY
when there are multiple choices. I assume we'd use the first available
value, as determined by the LSM list order, or the interface_lsm if we're
supporting that concept. And again, that's a problem for the complete
stacking round.

> https://github.com/SELinuxProject/selinux-kernel/issues/24
>
> For SO_PEERSEC, we should probably just introduce SO_PEERSEC2 or
> similar, using the same multi-LSM context structures as the other
> interfaces.

Also sensible, although I think SO_PEERCONTEXT or SO_PEERCTX is a better
name than SO_PEERSEC2. Also a problem for complete stacking and it is
way to early for me to get into bikeshedding.

>>> In case it helps spur your imagination, here is a revised strawman:
>>>
>>> /**
>>>  * struct lsm_ctx - LSM context
>>>  * @id: the LSM id number, see LSM_ID_XXX
>> A LSM ID hard coded in a kernel header makes it harder to develop new
>> security modules.
> There is so much precedence for defining a token scalar value to
> represent a "thing" that I don't know where to begin.  Look at IANA,
> there are entire organizations that exist to map "things" to numbers.
>
> If you're objecting to assigning LSMs fixed integer numbers you've got
> to give me some very explicit reasons (complete with examples) as to
> why that would be a mistake.

I talked myself out of the objection below. Thanks for listening.

>> The security module can't be self contained. I say
>> that, but I acknowledge that I've done the same kind of thing with the
>> definition of the struct lsmblob. That isn't part of an external API
>> however.
> I'm not following you here.  See my comment above about better examples.
>
>> It may also interfere with Tetsuo's long standing request that
>> we don't do things that prevent the possibility of loadable security
>> modules at some point in the future.
> I already replied to Tetsuo's email, and while this particular point
> about LSM ID numbers wasn't directly addressed, my response there
> seems to apply equally well here: it's not so much about loadable
> LSMs, it's about out-of-tree LSMs.  These are two very different
> things, with different solutions.

Agreed.

>> On the other hand, there's no great way to include two variable length
>> strings in a structure like this. So unless we adopt something as ugly
>> as the nil byte scheme this is supposed to replace I expect we're stuck
>> with an LSM ID.
> I don't like making general comments, but when in doubt, consider me
> not-a-fan of string-based identifiers in APIs.  Give me token scalar
> values instead.

Works for me.

>>>  * @flags: LSM specific flags, zero if unused
>> For an API shouldn't this be a specific size? u32? I'm not really
>> up to date on the guidance regarding which it should be.
> Enh, sure, whatever.  You'll remember my initial comment about not
> being a syscall stylist; if the discussion has moved to seriously
> discussing the syscall prototypes we should likely start a new thread
> and bring in the syscall folks ... I vaguely remember there was a
> mailing list for syscalls and API changes ...

Good idea. I'm reading the official how-to-write-a-syscall documentation.


>> I will head in this direction. A couple questions:
>>
>> Would we want lsm_prev_ctx() as well as lsm_current_ctx(),
> I'm not sure I'm following your thinking, what would lsm_prev_ctx() do?

Instead of the values in /proc/.../attr/current you'd get the
values from /proc/.../attr/prev.


>> or should we use the lsm_ctx->flags to identify the provided
>> context? If we did that we should have an lsm_ctx() system call
>> that returns the current, prev, and whatever other security
>> module specific attributes might be associated with the process,
>> each identified in the flags field. While the "current" context
>> is usually what we're after, there may be cases where the other
>> attributes are desired.
> I don't understand what you mean by "prev"{ious} attributes.  I'm
> thinking of lsm_current_ctx() as a multi-LSM replacement for
> /proc/self/attr/current.  If, for example, we wanted something for
> /proc/self/attr/exec I imagine we would create lsm_current_exec(), or
> something similarly named, with a similar prototype.
>
> Or perhaps we try to stick a bit closer to the procfs naming and go
> with lsm_self_cur(...) and lsm_self_exec(...).  All things to discuss.

I'm thinking that a syscall lsm_self_attr() would get all of the attributes
that are available from /proc/.../attr today. Flags would identify what
kind of attribute they are:

	LSM_ATTR_CURRENT	0x0001 /* Current security context */
	LSM_ATTR_PREV		0x0002 /* Previous security context */
	LSM_ATTR_EXEC		0x0004 /* Exec security context */
	...
	LSM_ATTR_SOCREATE	0x0020 /* Socket creation context */

As you suggest above (with a touch of modification) lsm_self_current()
gets just the LSM_ATTR_CURRENT values, lsm_self_exec() gets the
LSM_ATTR_EXEC values. It would be easy to add new attributes and implement
library functions to filter them out rather than have to create new
syscalls every time a new attribute is added.

It might also be useful to have a flag value (See? You were right) for
the syscalls LSM_ATTR_INTERFACE_LSM which instructs the syscall to only
return the attribute values for the interface_lsm. Hmm. How about allowing
the caller to specify which security module they want the values for by
LSM ID? That could be useful although certainly not necessary. It could
make the user space processing more efficient. It would make converting
libselinux and libsmack to use the syscalls a little bit easier. I'm not
wedded to the LSM ID filter as the caller can always ignore data from
security modules it doesn't care about.

What about lsm_self_attr_set()? This seem rife with peril. Setting a group
of security attributes on a process could fail halfway through and then
require unwinding the preceding successes. I could see having this syscall
if it was only allowed to set a single attribute at a time.

lsm_pid_attr() would be like lsm_self_attr(), but would take a process id as
an additional parameter and get the values for the specified process. This
could make a bunch of dbus' /proc accesses unnecessary. It would have to be
quite a bit more complicated than lsm_self_attr() because it would have to
verify that the caller has appropriate access to the target process. We can
debate whether Smack can deny access to another process' SELinux context.
We can also debate whether an incomplete operation (you can get the SELinux
context, but not the AppArmor context) is an error.

I am going to start playing with these syscalls. Please help me understand
where I have suggested something stoopid.

Thank you.

Re: LSM stacking in next for 6.1?

[Tetsuo Handa]

On 2022/09/09 7:56, Casey Schaufler wrote:
> Good idea. I'm reading the official how-to-write-a-syscall documentation.

Can't we use prctl() syscall? We can assign an LSM ID when an (built-in or loadable) LSM
is loaded, and pass that LSM ID as one of arguments for prctl().

Since we have security_task_prctl(option, arg2, arg3, arg4, arg5) inside prctl(), an LSM 
which was assigned that LSM ID upon load checks arguments (including PID argument).
That will be something like ioctl() without open("/proc/pid/*/attr/*").

Re: LSM stacking in next for 6.1?

[Casey Schaufler]

On 9/9/2022 9:17 PM, Tetsuo Handa wrote:
> On 2022/09/09 7:56, Casey Schaufler wrote:
>> Good idea. I'm reading the official how-to-write-a-syscall documentation.
> Can't we use prctl() syscall? We can assign an LSM ID when an (built-in or loadable) LSM
> is loaded, and pass that LSM ID as one of arguments for prctl().

I'm not the fan of an LSM ID that Paul is, but if we're going to use them I much
prefer a static value to a dynamic one. Libraries/programs that have to query the
system to get the ID ( int selinuxid = lsm_get_id("selinux"); ) are harder to
maintain. It would really push us toward requiring a liblsm, which I think we're
still trying to avoid.

That doesn't give us a good answer for loadable modules. The last time I looked
seriously at loadable modules I was considering that we'd need a security module
that manages them, very much like BPF manages the eBPF programs. Loadable modules
could use prctl, or some other mechanism, but they would have to be different
from built-in modules. You can't require built-in modules to conform to the
restrictions you'd have to impose on loadable ones. The Loadable Module Security
Module would have a static ID and somehow multiplex what lsm_self_attr() reports.
I think it could be made to work. I can't say that it is something I am likely to
get to soon.

>
> Since we have security_task_prctl(option, arg2, arg3, arg4, arg5) inside prctl(), an LSM 
> which was assigned that LSM ID upon load checks arguments (including PID argument).
> That will be something like ioctl() without open("/proc/pid/*/attr/*").
>

Re: LSM stacking in next for 6.1?

[Tetsuo Handa]

On 2022/09/13 2:37, Casey Schaufler wrote:
> That doesn't give us a good answer for loadable modules. The last time I looked
> seriously at loadable modules I was considering that we'd need a security module
> that manages them, very much like BPF manages the eBPF programs. Loadable modules
> could use prctl, or some other mechanism, but they would have to be different
> from built-in modules. You can't require built-in modules to conform to the
> restrictions you'd have to impose on loadable ones.

What I'm requesting (in other words, the biggest barrier I want to solve) is

 security/security.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/security/security.c b/security/security.c
index 4b95de24bc8d..ed34e25af22b 100644
--- a/security/security.c
+++ b/security/security.c
@@ -73,6 +73,7 @@ const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
 };
 
 struct security_hook_heads security_hook_heads __lsm_ro_after_init;
+EXPORT_SYMBOL_GPL(security_hook_heads);
 static BLOCKING_NOTIFIER_HEAD(blocking_lsm_notifier_chain);
 
 static struct kmem_cache *lsm_file_cache;
-- 
2.18.4

and optionally (in other words, the second biggest barrier I want to solve is)

 security/security.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/security.c b/security/security.c
index ed34e25af22b..4cc09e6cb32a 100644
--- a/security/security.c
+++ b/security/security.c
@@ -72,7 +72,7 @@ const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
 	[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
 };
 
-struct security_hook_heads security_hook_heads __lsm_ro_after_init;
+struct security_hook_heads security_hook_heads;
 EXPORT_SYMBOL_GPL(security_hook_heads);
 static BLOCKING_NOTIFIER_HEAD(blocking_lsm_notifier_chain);
 
-- 
2.18.4

. A security module that manages loadable LSM modules cannot give us a good answer
if there is a kernel config option to disable the manager security module.

As long as the death sentence remains, being able to disallow loadable LSMs
is a very stupid decision. If a loadable kernel module were malicious, that
module can do what AKARI/CaitSith are doing today using more disguised code.
There should be a chance for ethical loadable LSM modules.

Kernels which seriously need security should be built with CONFIG_MODULES=n.
Kernels which want to use loadable modules (not limited to LSM) but still need to
remain secure should consider using e.g. CONFIG_MODULE_SIG=y.

I consider that real bugs which may crash/compromise the kernel are reported by
fuzz testing. Rather than disallowing loadable module LSMs, fixing real bugs
should be the way to proceed.

>                                                     The Loadable Module Security
> Module would have a static ID and somehow multiplex what lsm_self_attr() reports.

I don't think loadable module LSM have a static ID. TOMOYO/AKARI/CaitSith are already
working without "struct lsm_blob_sizes blob_sizes", without /proc/pid/attr/ interface,
without modification of userspace programs. TOMOYO/AKARI/CaitSith are designed to avoid
interface/resource conflicts you are trying to solve.

> I think it could be made to work. I can't say that it is something I am likely to
> get to soon.

The kernel config option and distribution's policy are preventing users from using
non-builtin LSMs in distributor's kernels. It is a trivial task to make TOMOYO work
in distributor's kernels if above-mentioned changes are accepted.

https://bugzilla.redhat.com/show_bug.cgi?id=542986

Re: LSM stacking in next for 6.1?

[Casey Schaufler]

On 9/13/2022 3:47 AM, Tetsuo Handa wrote:
> On 2022/09/13 2:37, Casey Schaufler wrote:
>> That doesn't give us a good answer for loadable modules. The last time I looked
>> seriously at loadable modules I was considering that we'd need a security module
>> that manages them, very much like BPF manages the eBPF programs. Loadable modules
>> could use prctl, or some other mechanism, but they would have to be different
>> from built-in modules. You can't require built-in modules to conform to the
>> restrictions you'd have to impose on loadable ones.
> What I'm requesting (in other words, the biggest barrier I want to solve) is
>
>  security/security.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/security/security.c b/security/security.c
> index 4b95de24bc8d..ed34e25af22b 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -73,6 +73,7 @@ const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
>  };
>  
>  struct security_hook_heads security_hook_heads __lsm_ro_after_init;
> +EXPORT_SYMBOL_GPL(security_hook_heads);
>  static BLOCKING_NOTIFIER_HEAD(blocking_lsm_notifier_chain);
>  
>  static struct kmem_cache *lsm_file_cache; -- 
> 2.18.4
>
> and optionally (in other words, the second biggest barrier I want to solve is)
>
>  security/security.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/security.c b/security/security.c
> index ed34e25af22b..4cc09e6cb32a 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -72,7 +72,7 @@ const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
>  	[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
>  };
>  
> -struct security_hook_heads security_hook_heads __lsm_ro_after_init;
> +struct security_hook_heads security_hook_heads;
>  EXPORT_SYMBOL_GPL(security_hook_heads);
>  static BLOCKING_NOTIFIER_HEAD(blocking_lsm_notifier_chain);

I don't see either of these changes happening. I'm not the right person
to argue either side, but I understand the rationale for keeping them
private. That's why I think we need to have a different mechanism for
loadable modules, and why it needs to be optional.

>  
> -- 
> 2.18.4
>
> . A security module that manages loadable LSM modules cannot give us a good answer
> if there is a kernel config option to disable the manager security module.

The community that is absolutely opposed to loadable modules will disagree.

> As long as the death sentence remains, being able to disallow loadable LSMs
> is a very stupid decision. If a loadable kernel module were malicious, that
> module can do what AKARI/CaitSith are doing today using more disguised code.
> There should be a chance for ethical loadable LSM modules.

My understanding of the argument is that while an in-tree, built in module
will be subject to appropriate review, you can't say that about an out-of-tree,
loadable module.

> Kernels which seriously need security should be built with CONFIG_MODULES=n.
> Kernels which want to use loadable modules (not limited to LSM) but still need to
> remain secure should consider using e.g. CONFIG_MODULE_SIG=y.
>
> I consider that real bugs which may crash/compromise the kernel are reported by
> fuzz testing. Rather than disallowing loadable module LSMs, fixing real bugs
> should be the way to proceed.

A significant portion (maybe the majority) of security work being done
today is based on the notion that we can't fix all the bugs or exclude all
the malicious code, so we better protect specific bits of code from the
rest. Fuzz testing is a wonderful tool, but won't find everything.

> >                                                     The Loadable Module Security
> > Module would have a static ID and somehow multiplex what lsm_self_attr() reports.
>
> I don't think loadable module LSM have a static ID. TOMOYO/AKARI/CaitSith are already
> working without "struct lsm_blob_sizes blob_sizes", without /proc/pid/attr/ interface,
> without modification of userspace programs. TOMOYO/AKARI/CaitSith are designed to avoid
> interface/resource conflicts you are trying to solve.

A loadable module would have to be managed differently from a built-in one.
Hence the notion of a loadable module manager.

> > I think it could be made to work. I can't say that it is something I am likely to
> > get to soon.
>
> The kernel config option and distribution's policy are preventing users from using
> non-builtin LSMs in distributor's kernels. It is a trivial task to make TOMOYO work
> in distributor's kernels if above-mentioned changes are accepted.

You should be able to use TOMOYO as a built-in along side other security modules
today. Aside from getting the distribution to include it in their kernel
configuration, which is admittedly no mean feat, and getting any user-space you
need included, you should already have what you need.

> https://bugzilla.redhat.com/show_bug.cgi?id=542986

Ten years ago they said "Don't want to, aren't going to". Sadly, I doubt
there would be a different attitude today. The decision to support a security
module in a distribution is serious. I can definitely see how Redhat would
have their hands full supporting SELinux.

Re: LSM stacking in next for 6.1?

[Tetsuo Handa]

On 2022/09/13 23:45, Casey Schaufler wrote:
>> . A security module that manages loadable LSM modules cannot give us a good answer
>> if there is a kernel config option to disable the manager security module.
> 
> The community that is absolutely opposed to loadable modules will disagree.

Who are members of that community?

Hiding security_hook_heads from /proc/kallsyms has no value from security
perspective, for malicious loadable kernel modules can calculate the address
of security_hook_heads based on addresses of relevant functions and byte-code
in the relevant functions.

Keeping __lsm_ro_after_init might have a little value, but at the same time
it might make kernel less secure (or more prone to memory corruption) due to
the need to pass rodata=0 kernel command line option when a loadable module
LSM is loaded.



>> The kernel config option and distribution's policy are preventing users from using
>> non-builtin LSMs in distributor's kernels. It is a trivial task to make TOMOYO work
>> in distributor's kernels if above-mentioned changes are accepted.
> 
> You should be able to use TOMOYO as a built-in along side other security modules
> today. Aside from getting the distribution to include it in their kernel
> configuration, which is admittedly no mean feat, and getting any user-space you
> need included, you should already have what you need.

That's a chicken-and-egg problem.

Yes, we can use TOMOYO as a built-in along side other security modules for
_user-built_ kernels. But no, we can't use TOMOYO for _distributor-built_ kernels
(namely, Fedora/CentOS Stream/RHEL kernels).

>> https://bugzilla.redhat.com/show_bug.cgi?id=542986
> 
> Ten years ago they said "Don't want to, aren't going to". Sadly, I doubt
> there would be a different attitude today. The decision to support a security
> module in a distribution is serious. I can definitely see how Redhat would
> have their hands full supporting SELinux.

Please distinguish the difference between "enable" and "support" at
https://bugzilla.redhat.com/show_bug.cgi?id=542986#c7 . (By the way,
I hate the word "support", for nobody can share agreed definition.)

"enable" is something like "available", "allow to exist".

"support" is something like "guaranteed", "provide efforts for fixing bugs".

However, in the Red Hat's world, "enable" == "support". The kernel config options
enabled by Red Hat is supported by Red Hat, and the kernel config options Red Hat
cannot support cannot be enabled by Red Hat.

On the contrary, in the vanilla kernel's world, the in-tree version of TOMOYO
cannot be built as a loadable module LSM. And it is impossible to built TOMOYO
as a loadable module LSM (so that TOMOYO can be used without the "support" by
Red Hat). As a result, users cannot try LSMs (either in-tree or out-of-tree)
other than SELinux.

The negative effect is not limited to TOMOYO.
Like Paul Moore said

  However, I will caution that it is becoming increasingly difficult for people
  to find time to review potential new LSMs so it may a while to attract sufficient
  comments and feedback.

, being unable to legally use loadable LSMs deprives of chances to develop/try
new LSMs, and makes LSM interface more and more unattractive. The consequence
would be "The LSM interface is dead. We will give up implementing as LSMs."

It is exactly "only in-tree and supported by distributors is correct" crap.

I don't like closed-source kernel modules that rewrite syscall tables (e.g.
used by AntiVirus), for I can't analyze problems when something went wrong.
If LSMs were available to open-source out-of-tree kernel modules, this situation
could be improved.



I think that syzbot is the most aggressive tester of TOMOYO security module.
But how many bugs did syzbot found in TOMOYO? How many distributors that
enabled TOMOYO in their kernels got bug reports regarding TOMOYO?

There might be reports like "When do you start providing ready-made policy
configurations?", but what Josh Boyer worried at
https://bugzilla.redhat.com/show_bug.cgi?id=542986#c8

  Simply put, we do not have the time to deal with any potential kernel bug
  reports that would come from enabling TOMOYO.  It would be a disservice to
  our users to enable something we have no intention of attempting to fix
  when it is broken.

did not happen, and

  Even if it was 100% perfect code and caused no bug reports for the kernel,
  it is still bloat and while it might not seem like it we are actually
  trying to cut down on the size of our installed kernels.

can be solved by allowing loadable module LSMs.

Loadable module LSM also breaks distributor's "enable" == "support" spell.



> A loadable module would have to be managed differently from a built-in one.
> Hence the notion of a loadable module manager.

We can make management up to module authors, like the comment of security_delete_hooks().
(Well, I'm not proposing ability to unload. I'm proposing only ability to load LSMs
as loadable kernel modules.)

Re: LSM stacking in next for 6.1?

[Casey Schaufler]

On 9/14/2022 6:57 AM, Tetsuo Handa wrote:
> On 2022/09/13 23:45, Casey Schaufler wrote:
>>> . A security module that manages loadable LSM modules cannot give us a good answer
>>> if there is a kernel config option to disable the manager security module.
>> The community that is absolutely opposed to loadable modules will disagree.
> Who are members of that community?
>
> Hiding security_hook_heads from /proc/kallsyms has no value from security
> perspective, for malicious loadable kernel modules can calculate the address
> of security_hook_heads based on addresses of relevant functions and byte-code
> in the relevant functions.
>
> Keeping __lsm_ro_after_init might have a little value, but at the same time
> it might make kernel less secure (or more prone to memory corruption) due to
> the need to pass rodata=0 kernel command line option when a loadable module
> LSM is loaded.
>
>
>
>>> The kernel config option and distribution's policy are preventing users from using
>>> non-builtin LSMs in distributor's kernels. It is a trivial task to make TOMOYO work
>>> in distributor's kernels if above-mentioned changes are accepted.
>> You should be able to use TOMOYO as a built-in along side other security modules
>> today. Aside from getting the distribution to include it in their kernel
>> configuration, which is admittedly no mean feat, and getting any user-space you
>> need included, you should already have what you need.
> That's a chicken-and-egg problem.
>
> Yes, we can use TOMOYO as a built-in along side other security modules for
> _user-built_ kernels. But no, we can't use TOMOYO for _distributor-built_ kernels
> (namely, Fedora/CentOS Stream/RHEL kernels).
>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=542986
>> Ten years ago they said "Don't want to, aren't going to". Sadly, I doubt
>> there would be a different attitude today. The decision to support a security
>> module in a distribution is serious. I can definitely see how Redhat would
>> have their hands full supporting SELinux.
> Please distinguish the difference between "enable" and "support" at
> https://bugzilla.redhat.com/show_bug.cgi?id=542986#c7 . (By the way,
> I hate the word "support", for nobody can share agreed definition.)
>
> "enable" is something like "available", "allow to exist".
>
> "support" is something like "guaranteed", "provide efforts for fixing bugs".
>
> However, in the Red Hat's world, "enable" == "support". The kernel config options
> enabled by Red Hat is supported by Red Hat, and the kernel config options Red Hat
> cannot support cannot be enabled by Red Hat.

The "enable" == "support" model in consistent with the expectations of
paying customers. 

> On the contrary, in the vanilla kernel's world, the in-tree version of TOMOYO
> cannot be built as a loadable module LSM. And it is impossible to built TOMOYO
> as a loadable module LSM (so that TOMOYO can be used without the "support" by
> Red Hat). As a result, users cannot try LSMs (either in-tree or out-of-tree)
> other than SELinux.

That is correct. Redhat has chosen to support only SELinux. If you want
TOMOYO to be enabled in a distribution you need to sell the value to a
distributor (really, really hard) Or (not recommended) become one yourself.

> The negative effect is not limited to TOMOYO.
> Like Paul Moore said
>
>   However, I will caution that it is becoming increasingly difficult for people
>   to find time to review potential new LSMs so it may a while to attract sufficient
>   comments and feedback.
>
> , being unable to legally use loadable LSMs deprives of chances to develop/try
> new LSMs, and makes LSM interface more and more unattractive. The consequence
> would be "The LSM interface is dead. We will give up implementing as LSMs."
>
> It is exactly "only in-tree and supported by distributors is correct" crap.

That's not quite the position. "Only in-tree, and someone has to want to use it
in the real world" is more accurate. Android isn't a distribution, neither is
Tizen. Having a major distributor include the LSM is a big plus.

>
> I don't like closed-source kernel modules that rewrite syscall tables (e.g.
> used by AntiVirus), for I can't analyze problems when something went wrong.
> If LSMs were available to open-source out-of-tree kernel modules, this situation
> could be improved.
>
>
>
> I think that syzbot is the most aggressive tester of TOMOYO security module.
> But how many bugs did syzbot found in TOMOYO? How many distributors that
> enabled TOMOYO in their kernels got bug reports regarding TOMOYO?
>
> There might be reports like "When do you start providing ready-made policy
> configurations?", but what Josh Boyer worried at
> https://bugzilla.redhat.com/show_bug.cgi?id=542986#c8
>
>   Simply put, we do not have the time to deal with any potential kernel bug
>   reports that would come from enabling TOMOYO.  It would be a disservice to
>   our users to enable something we have no intention of attempting to fix
>   when it is broken.
>
> did not happen, and
>
>   Even if it was 100% perfect code and caused no bug reports for the kernel,
>   it is still bloat and while it might not seem like it we are actually
>   trying to cut down on the size of our installed kernels.
>
> can be solved by allowing loadable module LSMs.
>
> Loadable module LSM also breaks distributor's "enable" == "support" spell.

It sure does. I'm waiting to see what happens if eBPF security modules
become popular. I can easily see distributions turning the BPF LSM off.

>> A loadable module would have to be managed differently from a built-in one.
>> Hence the notion of a loadable module manager.
> We can make management up to module authors, like the comment of security_delete_hooks().
> (Well, I'm not proposing ability to unload. I'm proposing only ability to load LSMs
> as loadable kernel modules.)

Exactly. A module would have to chose between being built-in and being loadable.
Before I go any further, I think that the loadable module manager LSM would be
very hard to get upstream. Most of the arguments against general support for
loadable modules would still apply. It is possible that an acceptable module
could be created, but it would have to address a lot of issues. It is a challenge
I don't expect to accept in this lifetime.

Re: LSM stacking in next for 6.1?

[Tetsuo Handa]

On 2022/09/15 0:50, Casey Schaufler wrote:
> On 9/14/2022 6:57 AM, Tetsuo Handa wrote:
>> Please distinguish the difference between "enable" and "support" at
>> https://bugzilla.redhat.com/show_bug.cgi?id=542986#c7 . (By the way,
>> I hate the word "support", for nobody can share agreed definition.)
>>
>> "enable" is something like "available", "allow to exist".
>>
>> "support" is something like "guaranteed", "provide efforts for fixing bugs".
>>
>> However, in the Red Hat's world, "enable" == "support". The kernel config options
>> enabled by Red Hat is supported by Red Hat, and the kernel config options Red Hat
>> cannot support cannot be enabled by Red Hat.
> 
> The "enable" == "support" model in consistent with the expectations of
> paying customers. 

Regarding CONFIG_MODULES=y,
"Vendor-A enables module-A" == "Vendor-A provides support for module-A" and
"Vendor-B enables module-B" == "Vendor-B provides support for module-B".

Regarding CONFIG_SECURITY=y (namely in the RH world),
"Distributor-A enables LSM-A" == "Distributor-A provides support for LSM-A".
However, "Distributor-A does not enable LSM-B" == "Some vendor is impossible to
provide support for LSM-B".

"Distributor-A does not enable module-B" == "Distributor-A is not responsible for
providing support for module-B" and "Vendor-B enables LSM-B" == "Vendor-B provides
support for LSM-B" are what I expect.

Current LSM interface does not allow LSM-B to exist in Distributor-A's systems.
The "enable" == "support" model should be allowed for LSM interface as well.
What a strange asymmetry rule!



>> On the contrary, in the vanilla kernel's world, the in-tree version of TOMOYO
>> cannot be built as a loadable module LSM. And it is impossible to built TOMOYO
>> as a loadable module LSM (so that TOMOYO can be used without the "support" by
>> Red Hat). As a result, users cannot try LSMs (either in-tree or out-of-tree)
>> other than SELinux.
> 
> That is correct. Redhat has chosen to support only SELinux. If you want
> TOMOYO to be enabled in a distribution you need to sell the value to a
> distributor (really, really hard) Or (not recommended) become one yourself.

What I'm asking is "allow non-SELinux to exist in RH systems".
I'm not asking RH to "provide efforts for fixing non-SELinux".
Being able to build in-tree version of TOMOYO via "make M=security/tomoyo"
releases RH from the "enable" == "support" spell.

Re: LSM stacking in next for 6.1?

[John Johansen]

On 9/15/22 07:27, Tetsuo Handa wrote:
> On 2022/09/15 0:50, Casey Schaufler wrote:
>> On 9/14/2022 6:57 AM, Tetsuo Handa wrote:
>>> Please distinguish the difference between "enable" and "support" at
>>> https://bugzilla.redhat.com/show_bug.cgi?id=542986#c7 . (By the way,
>>> I hate the word "support", for nobody can share agreed definition.)
>>>
>>> "enable" is something like "available", "allow to exist".
>>>
>>> "support" is something like "guaranteed", "provide efforts for fixing bugs".
>>>
>>> However, in the Red Hat's world, "enable" == "support". The kernel config options
>>> enabled by Red Hat is supported by Red Hat, and the kernel config options Red Hat
>>> cannot support cannot be enabled by Red Hat.
>>
>> The "enable" == "support" model in consistent with the expectations of
>> paying customers.
> 
> Regarding CONFIG_MODULES=y,
> "Vendor-A enables module-A" == "Vendor-A provides support for module-A" and
> "Vendor-B enables module-B" == "Vendor-B provides support for module-B".
> 
> Regarding CONFIG_SECURITY=y (namely in the RH world),
> "Distributor-A enables LSM-A" == "Distributor-A provides support for LSM-A".
> However, "Distributor-A does not enable LSM-B" == "Some vendor is impossible to
> provide support for LSM-B".
> 
> "Distributor-A does not enable module-B" == "Distributor-A is not responsible for
> providing support for module-B" and "Vendor-B enables LSM-B" == "Vendor-B provides
> support for LSM-B" are what I expect.
> 
> Current LSM interface does not allow LSM-B to exist in Distributor-A's systems.
> The "enable" == "support" model should be allowed for LSM interface as well.
> What a strange asymmetry rule!
> 
> 
> 
>>> On the contrary, in the vanilla kernel's world, the in-tree version of TOMOYO
>>> cannot be built as a loadable module LSM. And it is impossible to built TOMOYO
>>> as a loadable module LSM (so that TOMOYO can be used without the "support" by
>>> Red Hat). As a result, users cannot try LSMs (either in-tree or out-of-tree)
>>> other than SELinux.
>>
>> That is correct. Redhat has chosen to support only SELinux. If you want
>> TOMOYO to be enabled in a distribution you need to sell the value to a
>> distributor (really, really hard) Or (not recommended) become one yourself.
> 
> What I'm asking is "allow non-SELinux to exist in RH systems".
> I'm not asking RH to "provide efforts for fixing non-SELinux".
> Being able to build in-tree version of TOMOYO via "make M=security/tomoyo"
> releases RH from the "enable" == "support" spell.
> 

I am sympathetic, I want this too. But RH choices are not a technical problem,
they could easily enable and not support other LSMs (eg. Ubuntu does). It is a
political problem and I don't see loadable LSMs changing this.

Re: LSM stacking in next for 6.1?

[John Johansen]

On 9/14/22 06:57, Tetsuo Handa wrote:
> On 2022/09/13 23:45, Casey Schaufler wrote:
>>> . A security module that manages loadable LSM modules cannot give us a good answer
>>> if there is a kernel config option to disable the manager security module.
>>
>> The community that is absolutely opposed to loadable modules will disagree.
> 
> Who are members of that community?
> 
> Hiding security_hook_heads from /proc/kallsyms has no value from security
> perspective, for malicious loadable kernel modules can calculate the address
> of security_hook_heads based on addresses of relevant functions and byte-code
> in the relevant functions.
> 
> Keeping __lsm_ro_after_init might have a little value, but at the same time
> it might make kernel less secure (or more prone to memory corruption) due to
> the need to pass rodata=0 kernel command line option when a loadable module
> LSM is loaded.
> 
> 
> 
>>> The kernel config option and distribution's policy are preventing users from using
>>> non-builtin LSMs in distributor's kernels. It is a trivial task to make TOMOYO work
>>> in distributor's kernels if above-mentioned changes are accepted.
>>
>> You should be able to use TOMOYO as a built-in along side other security modules
>> today. Aside from getting the distribution to include it in their kernel
>> configuration, which is admittedly no mean feat, and getting any user-space you
>> need included, you should already have what you need.
> 
> That's a chicken-and-egg problem.
> 
> Yes, we can use TOMOYO as a built-in along side other security modules for
> _user-built_ kernels. But no, we can't use TOMOYO for _distributor-built_ kernels
> (namely, Fedora/CentOS Stream/RHEL kernels).
> 
>>> https://bugzilla.redhat.com/show_bug.cgi?id=542986
>>
>> Ten years ago they said "Don't want to, aren't going to". Sadly, I doubt
>> there would be a different attitude today. The decision to support a security
>> module in a distribution is serious. I can definitely see how Redhat would
>> have their hands full supporting SELinux.
> 
> Please distinguish the difference between "enable" and "support" at
> https://bugzilla.redhat.com/show_bug.cgi?id=542986#c7 . (By the way,
> I hate the word "support", for nobody can share agreed definition.)
> 
> "enable" is something like "available", "allow to exist".
> 
> "support" is something like "guaranteed", "provide efforts for fixing bugs".
> 
> However, in the Red Hat's world, "enable" == "support". The kernel config options
> enabled by Red Hat is supported by Red Hat, and the kernel config options Red Hat
> cannot support cannot be enabled by Red Hat.
> 
> On the contrary, in the vanilla kernel's world, the in-tree version of TOMOYO
> cannot be built as a loadable module LSM. And it is impossible to built TOMOYO
> as a loadable module LSM (so that TOMOYO can be used without the "support" by
> Red Hat). As a result, users cannot try LSMs (either in-tree or out-of-tree)
> other than SELinux.
> 
> The negative effect is not limited to TOMOYO.
> Like Paul Moore said
> 
>    However, I will caution that it is becoming increasingly difficult for people
>    to find time to review potential new LSMs so it may a while to attract sufficient
>    comments and feedback.
> 
> , being unable to legally use loadable LSMs deprives of chances to develop/try
> new LSMs, and makes LSM interface more and more unattractive. The consequence
> would be "The LSM interface is dead. We will give up implementing as LSMs."
> 
> It is exactly "only in-tree and supported by distributors is correct" crap.
> 

for some users, but having a very well defined support surface also has its
place. From a distro POV support is expensive and its amazing what users
will do and try to hide while trying to get support.

Personally I prefer splitting enable and support but there are situations
where that isn't even allowed (some certifications). So I can understand
where they are coming from.

It just sucks for the users and projects that aren't "supported".

> I don't like closed-source kernel modules that rewrite syscall tables (e.g.
> used by AntiVirus), for I can't analyze problems when something went wrong.

Does anyone?

> If LSMs were available to open-source out-of-tree kernel modules, this situation
> could be improved.
> 
you are more optimistic than I am. What makes you think a distro like RH will
enable loading out-of-tree kernel modules if they aren't enabling TOMOYO
that is already in the kernel.

If loadable LSM modules are allowed, there will likely be a kernel config
to disable them and there will definitely be an interface that allows
blocking them. So whether via config option or run time control I don't
see RH allowing them.

> 
> 
> I think that syzbot is the most aggressive tester of TOMOYO security module.
> But how many bugs did syzbot found in TOMOYO? How many distributors that
> enabled TOMOYO in their kernels got bug reports regarding TOMOYO?
> 
> There might be reports like "When do you start providing ready-made policy
> configurations?", but what Josh Boyer worried at
> https://bugzilla.redhat.com/show_bug.cgi?id=542986#c8
> 
>    Simply put, we do not have the time to deal with any potential kernel bug
>    reports that would come from enabling TOMOYO.  It would be a disservice to
>    our users to enable something we have no intention of attempting to fix
>    when it is broken.
> 
> did not happen, and
> 
>    Even if it was 100% perfect code and caused no bug reports for the kernel,
>    it is still bloat and while it might not seem like it we are actually
>    trying to cut down on the size of our installed kernels.
> 
> can be solved by allowing loadable module LSMs.
> 
> Loadable module LSM also breaks distributor's "enable" == "support" spell.
> 

sadly I really don't think it will

> 
> 
>> A loadable module would have to be managed differently from a built-in one.
>> Hence the notion of a loadable module manager.
> 
> We can make management up to module authors, like the comment of security_delete_hooks().
> (Well, I'm not proposing ability to unload. I'm proposing only ability to load LSMs
> as loadable kernel modules.)
> 

Re: LSM stacking in next for 6.1?

[Tetsuo Handa]

On 2022/09/15 16:45, John Johansen wrote:
> On 9/14/22 06:57, Tetsuo Handa wrote:
> for some users, but having a very well defined support surface also has its
> place. From a distro POV support is expensive and its amazing what users
> will do and try to hide while trying to get support.
> 

I know support is expensive. But distributors are not the only organizations
who provide support. Non-distributors can provide efforts for fixing bugs.
(In fact, I'm debugging problems where distributors would not care/support.)

> Personally I prefer splitting enable and support but there are situations
> where that isn't even allowed (some certifications). So I can understand
> where they are coming from.

What certifications require that an LSM must not be loaded as a loadable kernel
module?

I can imagine that certification becomes void if uncertified/extra kernel modules
are loaded. But I can't imagine that ability to load some kernel module (either
LSM or not) is relevant to certification.

>> I don't like closed-source kernel modules that rewrite syscall tables (e.g.
>> used by AntiVirus), for I can't analyze problems when something went wrong.
> 
> Does anyone?

Yes. It took me whole 2 years to prove that a timeout problem happening in a RHEL
system using TrendMicro's DeepSecurity is caused by a loadable kernel module used
by DeepSecurity. It is really difficult to analyze problems with closed-source
kernel modules, for I can't guess what is happening from source code.

You can browse how a loadable kernel module (for TrendMicro's ServerProtect) would look like
at https://files.trendmicro.com/products/splx/splx_kernel_module-3.0.1.0024-src.tar.gz .
I'm expecting that such loadable kernel module becomes cleaner by legally allowing
loadable LSM modules.

> 
>> If LSMs were available to open-source out-of-tree kernel modules, this situation
>> could be improved.
>>
> you are more optimistic than I am. What makes you think a distro like RH will
> enable loading out-of-tree kernel modules if they aren't enabling TOMOYO
> that is already in the kernel.
> 
> If loadable LSM modules are allowed, there will likely be a kernel config
> to disable them and there will definitely be an interface that allows
> blocking them. So whether via config option or run time control I don't
> see RH allowing them.

An interface that allows blocking unwanted loadable kernel module (either LSM or not)
will be e.g. module signature verification. No special switch for LSM is needed.

The "Vendor-A enables module-A" == "Vendor-A provides support for module-A" and
"Vendor-B enables module-B" == "Vendor-B provides support for module-B" rule can
apply to non-SELinux LSMs.

Re: LSM stacking in next for 6.1?

[Tetsuo Handa]

On 2022/10/25 1:37, Casey Schaufler wrote:
>>  What I'm insisting is that "warrant the freedom to load
>> loadable LSM modules without recompiling the whole kernel".
> 
> Since security modules are optional and the LSM infrastructure
> itself is optional you can't ensure that any given kernel would
> support a loadable security module.

Like I propose adding EXPORT_SYMBOL_GPL(security_hook_heads),
I'm not taking about distributors who choose CONFIG_SECURITY=n.

>> Adding EXPORT_SYMBOL_GPL(security_hook_heads) is the only way that can "allow
>> LSM modules which distributors cannot support to be legally loaded".
> 
> I believe that I've identified an alternative. It isn't easy or cheap.

No. You are just handwaving/postponing the problem using something unknown
that is not yet shown as a workable code. Anything that can be disabled via
kernel config option cannot be an alternative.

  Quoting from https://lkml.kernel.org/r/2225aec6-f0f3-d38e-ee3c-6139a7c25a37@I-love.SAKURA.ne.jp
  > Like Paul Moore said
  > 
  >   However, I will caution that it is becoming increasingly difficult for people
  >   to find time to review potential new LSMs so it may a while to attract sufficient
  >   comments and feedback.
  > 
  > , being unable to legally use loadable LSMs deprives of chances to develop/try
  > new LSMs, and makes LSM interface more and more unattractive. The consequence
  > would be "The LSM interface is dead. We will give up implementing as LSMs."

The biggest problem is that quite few developers show interest in loadable LSM modules.
How many developers responded to this topic? Once the ability to allow loadable LSM
modules is technically lost, nobody shall be able to revive it. You will be happy with
ignoring poor people.

You are already and completely trapped into "only in-tree and supported by distributors
is correct" crap.

> Of course the upstream kernel isn't going to have LSM IDs for out-of-tree
> security modules. That's one of many reasons loadable modules are going to
> have to be treated differently from built-in modules, if they're allowed
> at all.

Then, I have to hate your idea of having fixed sized array.

Nacked-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>

Re: LSM stacking in next for 6.1?

[John Johansen]

On 10/25/22 02:48, Tetsuo Handa wrote:
> On 2022/10/25 1:37, Casey Schaufler wrote:
>>>   What I'm insisting is that "warrant the freedom to load
>>> loadable LSM modules without recompiling the whole kernel".
>>
>> Since security modules are optional and the LSM infrastructure
>> itself is optional you can't ensure that any given kernel would
>> support a loadable security module.
> 
> Like I propose adding EXPORT_SYMBOL_GPL(security_hook_heads),
> I'm not taking about distributors who choose CONFIG_SECURITY=n.
> 
>>> Adding EXPORT_SYMBOL_GPL(security_hook_heads) is the only way that can "allow
>>> LSM modules which distributors cannot support to be legally loaded".
>>
>> I believe that I've identified an alternative. It isn't easy or cheap.
> 
> No. You are just handwaving/postponing the problem using something unknown
> that is not yet shown as a workable code. Anything that can be disabled via
> kernel config option cannot be an alternative.
> 
Uhmmm, loadable LSM modules if they ever happen will have a kernel config.
If not distros will carry a patch just like they have for unprivileged
user namespaces. Trying to force distros to allow out of tree code just
isn't going to work.

>    Quoting from https://lkml.kernel.org/r/2225aec6-f0f3-d38e-ee3c-6139a7c25a37@I-love.SAKURA.ne.jp
>    > Like Paul Moore said
>    >
>    >   However, I will caution that it is becoming increasingly difficult for people
>    >   to find time to review potential new LSMs so it may a while to attract sufficient
>    >   comments and feedback.
>    >
>    > , being unable to legally use loadable LSMs deprives of chances to develop/try
>    > new LSMs, and makes LSM interface more and more unattractive. The consequence
>    > would be "The LSM interface is dead. We will give up implementing as LSMs."
> 
> The biggest problem is that quite few developers show interest in loadable LSM modules.
> How many developers responded to this topic? Once the ability to allow loadable LSM
> modules is technically lost, nobody shall be able to revive it. You will be happy with
> ignoring poor people.
> 
> You are already and completely trapped into "only in-tree and supported by distributors
> is correct" crap.
> 

no, Casey is not. He is trying to find a path forward to get LSM
stacking upstream sooner than later. He has made proposals that
admittedly you have not liked, but he has at least tried to propose
ideas that could work within the insane set of constraints.

>> Of course the upstream kernel isn't going to have LSM IDs for out-of-tree
>> security modules. That's one of many reasons loadable modules are going to
>> have to be treated differently from built-in modules, if they're allowed
>> at all.
> 
> Then, I have to hate your idea of having fixed sized array.
> 
> Nacked-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> 

Re: LSM stacking in next for 6.1?

[Tetsuo Handa]

On 2022/10/25 19:26, John Johansen wrote:
> no, Casey is not. He is trying to find a path forward to get LSM
> stacking upstream sooner than later. He has made proposals that
> admittedly you have not liked, but he has at least tried to propose
> ideas that could work within the insane set of constraints.

I'm OK with getting LSM stacking upstream. But changes made based on
only built-in modules are bad. If LSM id cannot be assigned to loadable
LSM modules at runtime because not all loadable LSM modules will be
in-tree in order to get an LSM id assigned, loadable LSM modules won't
be able to utilize e.g. lsm_module_list system call (or whatever
changes made while trying to unshare resources/interfaces currently
shared among SELinux/Smack/AppArmor).

It will be a complete reinvention of Linux security framework which is
merely borrowing hooks provided by LSM. That is no different from
duplicating existing LSM hooks and managing via completely different
set of interfaces (e.g. /proc/$pid/attr2/$lsmname/$filename ,
/sys/kernel/security2/$lsmname/$filename ). Such implementation is
no longer loadable LSM. It is LSM version 2. And I don't think that
such implementation will be accepted unless you agree to kill current
LSM (say, LSM version 1).

Re: LSM stacking in next for 6.1?

[Casey Schaufler]

On 10/25/2022 4:20 AM, Tetsuo Handa wrote:
> On 2022/10/25 19:26, John Johansen wrote:
>> no, Casey is not. He is trying to find a path forward to get LSM
>> stacking upstream sooner than later. He has made proposals that
>> admittedly you have not liked, but he has at least tried to propose
>> ideas that could work within the insane set of constraints.
> I'm OK with getting LSM stacking upstream. But changes made based on
> only built-in modules are bad. If LSM id cannot be assigned to loadable
> LSM modules at runtime because not all loadable LSM modules will be
> in-tree in order to get an LSM id assigned, loadable LSM modules won't
> be able to utilize e.g. lsm_module_list system call (or whatever
> changes made while trying to unshare resources/interfaces currently
> shared among SELinux/Smack/AppArmor).
>
> It will be a complete reinvention of Linux security framework which is
> merely borrowing hooks provided by LSM. That is no different from
> duplicating existing LSM hooks and managing via completely different
> set of interfaces (e.g. /proc/$pid/attr2/$lsmname/$filename ,
> /sys/kernel/security2/$lsmname/$filename ). Such implementation is
> no longer loadable LSM. It is LSM version 2. And I don't think that
> such implementation will be accepted unless you agree to kill current
> LSM (say, LSM version 1).

The counter argument to this statement is that BPF has been accepted
upstream. eBPF programs are different from built-in security modules.
There is no reason that a well implemented LSM that accepts loadable
modules *that are different* from built-in modules couldn't be created.
I seriously doubt that it would get upstream for all the reasons
usually cited. But there is nothing about the implementation I've proposed
that would prevent it.

Re: LSM stacking in next for 6.1?

[Tetsuo Handa]

On 2022/10/25 23:12, Casey Schaufler wrote:
> On 10/25/2022 4:20 AM, Tetsuo Handa wrote:
>> On 2022/10/25 19:26, John Johansen wrote:
>>> no, Casey is not. He is trying to find a path forward to get LSM
>>> stacking upstream sooner than later. He has made proposals that
>>> admittedly you have not liked, but he has at least tried to propose
>>> ideas that could work within the insane set of constraints.
>> I'm OK with getting LSM stacking upstream. But changes made based on
>> only built-in modules are bad. If LSM id cannot be assigned to loadable
>> LSM modules at runtime because not all loadable LSM modules will be
>> in-tree in order to get an LSM id assigned, loadable LSM modules won't
>> be able to utilize e.g. lsm_module_list system call (or whatever
>> changes made while trying to unshare resources/interfaces currently
>> shared among SELinux/Smack/AppArmor).
>>
>> It will be a complete reinvention of Linux security framework which is
>> merely borrowing hooks provided by LSM. That is no different from
>> duplicating existing LSM hooks and managing via completely different
>> set of interfaces (e.g. /proc/$pid/attr2/$lsmname/$filename ,
>> /sys/kernel/security2/$lsmname/$filename ). Such implementation is
>> no longer loadable LSM. It is LSM version 2. And I don't think that
>> such implementation will be accepted unless you agree to kill current
>> LSM (say, LSM version 1).
> 
> The counter argument to this statement is that BPF has been accepted
> upstream. eBPF programs are different from built-in security modules.
> There is no reason that a well implemented LSM that accepts loadable
> modules *that are different* from built-in modules couldn't be created.
> I seriously doubt that it would get upstream for all the reasons
> usually cited. But there is nothing about the implementation I've proposed
> that would prevent it.
> 

As an easy example, please show me an eBPF program that allows restricting where
to chroot to and allows configuring where to chroot to using /sys/kernel/security/
interface.

An loadable LSM consists of hooks (for filtering access requests) and interface
(for configuring rules whether to filter access requests).

Your LSM id approach makes it impossible to use interface (due to lack of LSM id
for loadable LSM modules) by loadable LSM modules. LSM id must not be limited to
built-in LSM modules.

Re: LSM stacking in next for 6.1?

[Casey Schaufler]

On 10/25/2022 3:12 PM, Tetsuo Handa wrote:
> On 2022/10/25 23:12, Casey Schaufler wrote:
>> On 10/25/2022 4:20 AM, Tetsuo Handa wrote:
>>> On 2022/10/25 19:26, John Johansen wrote:
>>>> no, Casey is not. He is trying to find a path forward to get LSM
>>>> stacking upstream sooner than later. He has made proposals that
>>>> admittedly you have not liked, but he has at least tried to propose
>>>> ideas that could work within the insane set of constraints.
>>> I'm OK with getting LSM stacking upstream. But changes made based on
>>> only built-in modules are bad. If LSM id cannot be assigned to loadable
>>> LSM modules at runtime because not all loadable LSM modules will be
>>> in-tree in order to get an LSM id assigned, loadable LSM modules won't
>>> be able to utilize e.g. lsm_module_list system call (or whatever
>>> changes made while trying to unshare resources/interfaces currently
>>> shared among SELinux/Smack/AppArmor).
>>>
>>> It will be a complete reinvention of Linux security framework which is
>>> merely borrowing hooks provided by LSM. That is no different from
>>> duplicating existing LSM hooks and managing via completely different
>>> set of interfaces (e.g. /proc/$pid/attr2/$lsmname/$filename ,
>>> /sys/kernel/security2/$lsmname/$filename ). Such implementation is
>>> no longer loadable LSM. It is LSM version 2. And I don't think that
>>> such implementation will be accepted unless you agree to kill current
>>> LSM (say, LSM version 1).
>> The counter argument to this statement is that BPF has been accepted
>> upstream. eBPF programs are different from built-in security modules.
>> There is no reason that a well implemented LSM that accepts loadable
>> modules *that are different* from built-in modules couldn't be created.
>> I seriously doubt that it would get upstream for all the reasons
>> usually cited. But there is nothing about the implementation I've proposed
>> that would prevent it.
>>
> As an easy example, please show me an eBPF program that allows restricting where
> to chroot to and allows configuring where to chroot to using /sys/kernel/security/
> interface.
>
> An loadable LSM consists of hooks (for filtering access requests) and interface
> (for configuring rules whether to filter access requests).
>
> Your LSM id approach makes it impossible to use interface (due to lack of LSM id
> for loadable LSM modules) by loadable LSM modules. LSM id must not be limited to
> built-in LSM modules.

I'm sorry that I am failing to communicate my understanding of why this
isn't true. You need a built-in LSM that loads and manages loadable
security modules. That LSM would have an LSM ID just like the BPF LSM
has a LSM ID. I have no doubt that there are multiple workable implementations,
as I have looked into many different ways to implement the stacking for
built-in modules. I am also sorry that I don't expect to have enough working
years left to even consider spending any more time on the problem. This is
a development effort for The Next Generation.

Re: LSM stacking in next for 6.1?

[Tetsuo Handa]

On 2022/10/26 7:41, Casey Schaufler wrote:
>             You need a built-in LSM that loads and manages loadable
> security modules.

That is no longer loadable LSM modules. A loadable LSM module must be capable of
loading any code and using any interface that is allowed to loadable kernel modules
using /sbin/insmod command. That is my understanding of what you have promised (and
the reason I am allowing you to continue working on LSM stacking before I make
CONFIG_SECURITY_TOMOYO=m).

>                   That LSM would have an LSM ID just like the BPF LSM
> has a LSM ID.

There can't be a LSM that manages loadable security modules. TOMOYO can't be loaded
via such LSM, for TOMOYO needs to e.g. create /sys/kernel/security/tomoyo/ interface.
A contained program like BPF can't get such flexibility, and a LSM that manages
loadable security modules can't manage flexible/unconfined programs.

>                   That LSM would have an LSM ID just like the BPF LSM
> has a LSM ID.

Whatever LSM modules that are in-tree will have an LSM id. But you must remember
that not all LSM modules are in-tree (and won't be able to get in-tree).
The LSM id I'm talking about is for LSM modules that cannot get in-tree.

>               I have no doubt that there are multiple workable implementations,
> as I have looked into many different ways to implement the stacking for
> built-in modules.

Please enumerate some that can satisfy our promise.

Even if there is a LSM that manages loadable LSMs, loadable LSMs can't get LSM id
because what loadable LSMs will do is beyond what the BPF LSM can do.
Loadable LSMs by nature needs to be able to have unique identifier (currently
module name, and you are trying to change from name to integer which some of
loadable LSMs cannot get).

>                   I am also sorry that I don't expect to have enough working
> years left to even consider spending any more time on the problem. This is
> a development effort for The Next Generation.

If you segregate built-in LSM modules and loadable LSM modules (remember,
not all LSM modules will be able to get in-tree and built-in), userspace won't be
able to use LSM id you are trying to introduce. Your LSM id makes LSM framework
worse than now.

You are killing The Next Generation due to "only in-tree and supported by
distributors is correct" crap.

Re: LSM stacking in next for 6.1?

[Casey Schaufler]

On 10/26/2022 3:19 AM, Tetsuo Handa wrote:
> On 2022/10/26 7:41, Casey Schaufler wrote:
>>             You need a built-in LSM that loads and manages loadable
>> security modules.
> That is no longer loadable LSM modules. A loadable LSM module must be capable of
> loading any code and using any interface that is allowed to loadable kernel modules
> using /sbin/insmod command. That is my understanding of what you have promised (and
> the reason I am allowing you to continue working on LSM stacking before I make
> CONFIG_SECURITY_TOMOYO=m).

Loadable modules, in whatever form they take, will require the stacking
I'm proposing. They will also require the next phase of stacking, which
includes the networking bits that will allow universal stacking. Even if
the current work goes in tomorrow (demented giggles) that's at least a
year off. Then, and only then, will someone be able to tackle an
implementation of loadable modules. I will not be available for that job.
I have done everything I can to ensure that the stacking work won't
prevent it from being done. I have proposed how it might be done. But
I don't have 10 more years to spend on it, and it's not me that will
reject it in the end. I won't beat that dead horse's head against that
brick wall.

Re: LSM stacking in next for 6.1?

[John Johansen]

On 10/26/22 03:19, Tetsuo Handa wrote:
> On 2022/10/26 7:41, Casey Schaufler wrote:
>>              You need a built-in LSM that loads and manages loadable
>> security modules.
> 
> That is no longer loadable LSM modules. A loadable LSM module must be capable of
> loading any code and using any interface that is allowed to loadable kernel modules
> using /sbin/insmod command. That is my understanding of what you have promised (and
> the reason I am allowing you to continue working on LSM stacking before I make
> CONFIG_SECURITY_TOMOYO=m).
> 

Tetsuo, think of it this way. LSM stacking is going to make it much easier for new
LSM modules because they won't automatically be excluded because one of the other
LSMs is needed.

The problem of loadable LSM modules is orthogonal, and Casey shouldn't need to
solve it in this patch series. That is further work to be taken up by another,
as Casey has clearly stated its work he is not interested in doing.

However the real problem you are trying to solve won't be solved by loadable LSM
modules, though they may help. Just having loadable LSMs modules won't mean a
distro will build an LSM as a loadable module instead of disabling it, nor does
it mean a distro will allow loading an out of tree LSM module. Even if the
upstream kernel doesn't provide an option to block loading them, distros will.

Re: LSM stacking in next for 6.1?

[Tetsuo Handa]

On 2022/10/28 19:14, John Johansen wrote:
> On 10/26/22 03:19, Tetsuo Handa wrote:
>> On 2022/10/26 7:41, Casey Schaufler wrote:
>>>              You need a built-in LSM that loads and manages loadable
>>> security modules.
>>
>> That is no longer loadable LSM modules. A loadable LSM module must be capable of
>> loading any code and using any interface that is allowed to loadable kernel modules
>> using /sbin/insmod command. That is my understanding of what you have promised (and
>> the reason I am allowing you to continue working on LSM stacking before I make
>> CONFIG_SECURITY_TOMOYO=m).
>>
> 
> Tetsuo, think of it this way. LSM stacking is going to make it much easier for new
> LSM modules because they won't automatically be excluded because one of the other
> LSMs is needed.
> 
> The problem of loadable LSM modules is orthogonal, and Casey shouldn't need to
> solve it in this patch series. That is further work to be taken up by another,
> as Casey has clearly stated its work he is not interested in doing.
> 
> However the real problem you are trying to solve won't be solved by loadable LSM
> modules, though they may help. Just having loadable LSMs modules won't mean a
> distro will build an LSM as a loadable module instead of disabling it, nor does
> it mean a distro will allow loading an out of tree LSM module. Even if the
> upstream kernel doesn't provide an option to block loading them, distros will.
> 

What do you think the background of

  Ultimately the challenge is getting userspace developers to accept a
  change that is not part of the upstream Linux Kernel and thus not
  guaranteed under the usual "don't break userspace" kernel API promise.

is? I consider that the reason is because

  We do care about userspace programs and users who are using userspace programs.

. If we don't care about userspace and users, we would not mind breaking APIs.
This reasoning is more stronger than "we don't care about out-of-tree code"
reasoning.

Distributors have rights to block loading loadable kernel modules which are
not included in upstream kernels. But for example Red Hat is not excising
the rights to block loading loadable kernel modules (e.g.
https://access.redhat.com/solutions/1376133 ). What do you think about the
reasons of not blocking loading loadable kernel modules which are not included
in upstream kernels? I consider that the reason is because

  Allowing loadable kernel modules which cannot be supported by distributors
  to exist and to be loaded into distributor kernels is more beneficial for
  users.

That is, we have been allowing out-of-tree kernel code to exist because
out-of-tree kernel code can be beneficial for users despite distributors cannot
afford supporting out-of-tree kernel code.

If you really think that we have the rights to lock out out-of-tree kernel code
and/or disable loading of out-of-tree kernel code via /sbin/insmod, firstly achieve

  (1) Disallow loading of non-GPL kernel modules. (It is a trivial change.)

  (2) Disallow loading of out-of-tree kernel code via /sbin/insmod .
      (I don't know how we can technically enforce such change. Unlike not assigning
      LSM id value to LSM modules, we need to somehow be able to check whether an
      arbitrary file is in-tree (e.g. forbid "git add some_file") and unmodified
      (e.g. forbid "patch -p1 < some_patch").

before you enforce requiring an LSM id value in order to register an LSM module.
I don't accept "I'm not interested in making such changes". It is your duty to
achieve if you use "we don't care about out-of-tree code" as a rationale for
requiring an LSM id value in order to register an LSM module.

Nowadays, many software is developed using programming languages which can generate code
for multiple operating systems. That is, people are getting indifferent with operating
systems they run their software. Then, what is an advantage of choosing Linux as operating
systems for running their software, if Linux kernel does not provide freedom for
customization depending on user's needs?

As web application developers increases, developers who can understand C language (and
system call) are decreasing. As a result, it is getting more and more difficult to let them
understand and manage fine-grained allowlisting-based access controls like SELinux. Then,
what is an advantage of choosing Linux as operating systems for running their software, if
LSM does not provide freedom for using whatever simpler LSM modules users want?

Windows operating system provides WSL (Windows Subsystem for Linux) which allows running
CUI programs and servers which are designed for Linux. Windows users can run CUI programs
and servers without requiring real Linux kernels and can run GUI programs via Windows
kernels. Neither SELinux nor AppArmor is required for protecting programs/servers, for
antivirus software for Windows will provide protection. Then, what is an advantage of using
real Linux kernels, if we cannot allow Linux kernels to use whatever LSM modules users want?

I believe that it is time to get out of "we don't care about out-of-tree code".
The "we don't care about out-of-tree code" reasoning is a brain freeze that leads to
forget about users who still continue using Linux as platform for running their software.

Re: LSM stacking in next for 6.1?

[John Johansen]

On 10/29/22 21:03, Tetsuo Handa wrote:
> On 2022/10/28 19:14, John Johansen wrote:
>> On 10/26/22 03:19, Tetsuo Handa wrote:
>>> On 2022/10/26 7:41, Casey Schaufler wrote:
>>>>               You need a built-in LSM that loads and manages loadable
>>>> security modules.
>>>
>>> That is no longer loadable LSM modules. A loadable LSM module must be capable of
>>> loading any code and using any interface that is allowed to loadable kernel modules
>>> using /sbin/insmod command. That is my understanding of what you have promised (and
>>> the reason I am allowing you to continue working on LSM stacking before I make
>>> CONFIG_SECURITY_TOMOYO=m).
>>>
>>
>> Tetsuo, think of it this way. LSM stacking is going to make it much easier for new
>> LSM modules because they won't automatically be excluded because one of the other
>> LSMs is needed.
>>
>> The problem of loadable LSM modules is orthogonal, and Casey shouldn't need to
>> solve it in this patch series. That is further work to be taken up by another,
>> as Casey has clearly stated its work he is not interested in doing.
>>
>> However the real problem you are trying to solve won't be solved by loadable LSM
>> modules, though they may help. Just having loadable LSMs modules won't mean a
>> distro will build an LSM as a loadable module instead of disabling it, nor does
>> it mean a distro will allow loading an out of tree LSM module. Even if the
>> upstream kernel doesn't provide an option to block loading them, distros will.
>>
> 
> What do you think the background of
> 
>    Ultimately the challenge is getting userspace developers to accept a
>    change that is not part of the upstream Linux Kernel and thus not
>    guaranteed under the usual "don't break userspace" kernel API promise.
> 
> is? I consider that the reason is because
> 
>    We do care about userspace programs and users who are using userspace programs.
> 
> . If we don't care about userspace and users, we would not mind breaking APIs.

Like it or not kernel developers draw a very distinct line between userspace APIs
and what is considered kernel code.

> This reasoning is more stronger than "we don't care about out-of-tree code"
> reasoning.
> 
Look many developers really just don't care about out of tree code, and others
well I won't say they don't care but its impossible task to monitor and think
about how the broad swath of different out of tree code bits could be affected
by kernel changes. So the only practical thing to do is make changes based on
what is in tree and let out of tree projects deal with making the adjustments
needed to adapt to the changing kernel.

This comes about because the kernel does NOT provide a stable ABI for out of
tree code. This is not a technical position as other projects do provide
stable ABIs for out of tree code, with varying degrees of success.

It is a community/political position that is certainly informed by technical
merits but also other considerations, like GPL, experience on the costs of
maintaining stable ABIs and a desire to where possible push for code inclusion
in the kernel.


> Distributors have rights to block loading loadable kernel modules which are
> not included in upstream kernels. But for example Red Hat is not excising
> the rights to block loading loadable kernel modules (e.g.
> https://access.redhat.com/solutions/1376133 ). What do you think about the
> reasons of not blocking loading loadable kernel modules which are not included
> in upstream kernels? I consider that the reason is because
> 
>    Allowing loadable kernel modules which cannot be supported by distributors
>    to exist and to be loaded into distributor kernels is more beneficial for
>    users.
> 

For some users yes. I am not saying a distro will want to block it for everyone
one every kernel just that they need the option. Ubuntu has taken the position
to try to be as inclusive as possible on the base distro kernels but even with
that position we have special kernels that take a very different approach.

> That is, we have been allowing out-of-tree kernel code to exist because
> out-of-tree kernel code can be beneficial for users despite distributors cannot
> afford supporting out-of-tree kernel code.
> 

yes, no argument

> If you really think that we have the rights to lock out out-of-tree kernel code
> and/or disable loading of out-of-tree kernel code via /sbin/insmod, firstly achieve
> 
>    (1) Disallow loading of non-GPL kernel modules. (It is a trivial change.)
> 
I have no desire to get involved the that debate :)

>    (2) Disallow loading of out-of-tree kernel code via /sbin/insmod .

Depending on the kernel we do it either by disabling the loading of modules or
via requiring modules to be signed. We have kernels that do this.


>        (I don't know how we can technically enforce such change. Unlike not assigning
>        LSM id value to LSM modules, we need to somehow be able to check whether an
>        arbitrary file is in-tree (e.g. forbid "git add some_file") and unmodified
>        (e.g. forbid "patch -p1 < some_patch").
> 

Just because LSM ids are currently statically assigned doesn't mean that has to
be the case for all LSMs. I don't see a technical reason why an interface to
request and assign dynamic IDs can't be added in the future.


> before you enforce requiring an LSM id value in order to register an LSM module.
> I don't accept "I'm not interested in making such changes". It is your duty to
> achieve if you use "we don't care about out-of-tree code" as a rationale for
> requiring an LSM id value in order to register an LSM module.
> 

As I said before, not a technical problem but a social/political one. I am
sympathetic. I do care about out of tree code, I do see benefit to it, but I also
understand the kernel community not wanting to have to try and make decisions
about kernel code based on it.

The LSM id is far from the only problem out of tree code has to deal with. It has
to deal with changing structures, functions parameters, hooks, functions going
away, changes to locking semantics (rt kernel changes). For out of tree code to
be built against multiple kernels it has to already deal with all of this.
I don't see the LSM id as that different of a barrier and there are certainly
potential paths forward like adding the ability to request an id.

> Nowadays, many software is developed using programming languages which can generate code
> for multiple operating systems. That is, people are getting indifferent with operating
> systems they run their software. Then, what is an advantage of choosing Linux as operating
> systems for running their software, if Linux kernel does not provide freedom for
> customization depending on user's needs?
> 

Uhhmmm wow. They can customize Linux to their hearts content, the code is available.
Beyond that Linux has never offered a stable ABI for modules. Only modules built
with the kernel. Yes you can build modules out of tree, but then the module has
to adapt to kernel changes. The LSM id is far from the only change out of tree
code will have to deal with.

> As web application developers increases, developers who can understand C language (and
> system call) are decreasing. As a result, it is getting more and more difficult to let them
> understand and manage fine-grained allowlisting-based access controls like SELinux. Then,
> what is an advantage of choosing Linux as operating systems for running their software, if
> LSM does not provide freedom for using whatever simpler LSM modules users want?
> 
Linux does allow this, its just not as easy as it could be, and it is not what
you want. And if this is what those application developers need then maybe Linux
is not the right platform for them.

Like it or not, not exporting the security_hook_heads was not a technical
decision. I am not opposed to

   EXPORT_SYMBOL_GPL(security_hook_heads)

but others are and I don't know how to change that.

> Windows operating system provides WSL (Windows Subsystem for Linux) which allows running
> CUI programs and servers which are designed for Linux. Windows users can run CUI programs
> and servers without requiring real Linux kernels and can run GUI programs via Windows
> kernels. Neither SELinux nor AppArmor is required for protecting programs/servers, for

Actually WSL2 is now preferred over WSL and it does use the Linux kernel.

> antivirus software for Windows will provide protection. Then, what is an advantage of using
> real Linux kernels, if we cannot allow Linux kernels to use whatever LSM modules users want?
> 

Sorry I don't see the argument. With that sad I will say the Window kernel
doesn't allow running arbitrary out of tree code. Modules must be signed and
the Kernel is closed source. So if you want something custom Linux is ahead
of the game there.

Would I like to see more LSM modules, yes. That is part of why I want stacking
to land. We have been faffing around on its details for 10+ years, and I
think we likely would have seen more modules by now if it had landed. I
also think having it landed would allow for people to propose patches to
extend and improve it instead of arguing about it.

> I believe that it is time to get out of "we don't care about out-of-tree code".

Unless Linux is willing to offer a stable ABIs to out of tree code this is
impossible. Developers just can't consider all the out of tree code when they
are making code changes. And I don't see Linux being willing to offer a
stable ABI to out of tree modules.

> The "we don't care about out-of-tree code" reasoning is a brain freeze that leads to
> forget about users who still continue using Linux as platform for running their software.
> 

I get what you are saying. But again this isn't a technical problem and
I don't have a solution. What we need right now is constructive review
and preferably code to move patches forward so we can get stacking landed.

Re: LSM stacking in next for 6.1?

[Tetsuo Handa]

On 2022/10/30 16:23, John Johansen wrote:
>> This reasoning is more stronger than "we don't care about out-of-tree code"
>> reasoning.
>>
> Look many developers really just don't care about out of tree code, and others
> well I won't say they don't care but its impossible task to monitor and think
> about how the broad swath of different out of tree code bits could be affected
> by kernel changes. So the only practical thing to do is make changes based on
> what is in tree and let out of tree projects deal with making the adjustments
> needed to adapt to the changing kernel.

I don't care that out of tree projects have to deal with the burden of making
the adjustments needed to adapt to the changing kernel. But I do care that
out of tree projects are allowed to make the adjustments needed to adapt to
the changing kernel.

Think about the PCI ID Repository ( https://pci-ids.ucw.cz ) as an example.

A PCI ID value can be assigned to a hardware device, regardless of whether
a device driver for Linux kernel is available in the upstream kernel.

Casey's patchset is trying to provide LSM ID Repository for userspace programs.
But an LSM ID value cannot be assigned to that LSM unless that module is
available in the upstream kernel. This means that, developers are not allowed
to develop a new LSM module even with the intention to become available in the
upstream kernel, for there always is a risk of LSM ID collision which the LSM ID
Repository should have avoided from the beginning. Also, this means that, unlike
PCI devices, users are not allowed to use out-of-tree LSM modules which have to
remain out-of-tree due to proposed-but-not-accepted by the upstream kernel.
This is a serious bug; is LSM a proprietary/closed code where modification is
impossible due to an End-User License Agreement?


You have only three choices:

  (1) allow assigning LSM ID integer value to all LSM modules (regardless of
      whether that module was merged into upstream kernel)

  (2) use module name string value as LSM ID

  (3) dynamically assign LSM ID integer value when an LSM module is registered

There never is fourth choice:

  (4) assigning LSM ID integer value to only LSM modules which were merged
      into upstream kernel

The fourth choice is complete lockout of out of tree projects.

Re: LSM stacking in next for 6.1?

[Kees Cook]

On October 30, 2022 7:02:52 AM PDT, Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:
>Casey's patchset is trying to provide LSM ID Repository for userspace programs.
>But an LSM ID value cannot be assigned to that LSM unless that module is
>available in the upstream kernel. This means that, developers are not allowed
>to develop a new LSM module even with the intention to become available in the
>upstream kernel, for there always is a risk of LSM ID collision which the LSM ID
>Repository should have avoided from the beginning. Also, this means that, unlike
>PCI devices, users are not allowed to use out-of-tree LSM modules which have to
>remain out-of-tree due to proposed-but-not-accepted by the upstream kernel.
>This is a serious bug; is LSM a proprietary/closed code where modification is
>impossible due to an End-User License Agreement?

You are way off in the weeds with false equivalencies.

>You have only three choices:
>
>  (1) allow assigning LSM ID integer value to all LSM modules (regardless of
>      whether that module was merged into upstream kernel)

We are not hardware manufacturers.

>  (2) use module name string value as LSM ID

This results is greater code complexity. If you see a way to do this, send a patch. Instead of unhelpfully saying "no, do it differently", show a solution.

>  (3) dynamically assign LSM ID integer value when an LSM module is registered

Again, send a patch.

>There never is fourth choice:
>
>  (4) assigning LSM ID integer value to only LSM modules which were merged
>      into upstream kernel
>
>The fourth choice is complete lockout of out of tree projects.

This is just not a real outcome. How is this any different from syscalls, capability bits, prctl values, ELF flags, etc?


-- 
Kees Cook

Re: LSM stacking in next for 6.1?

[Casey Schaufler]

On 10/30/2022 9:37 AM, Kees Cook wrote:
> On October 30, 2022 7:02:52 AM PDT, Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:
>> Casey's patchset is trying to provide LSM ID Repository for userspace programs.
>> But an LSM ID value cannot be assigned to that LSM unless that module is
>> available in the upstream kernel. This means that, developers are not allowed
>> to develop a new LSM module even with the intention to become available in the
>> upstream kernel, for there always is a risk of LSM ID collision which the LSM ID
>> Repository should have avoided from the beginning. Also, this means that, unlike
>> PCI devices, users are not allowed to use out-of-tree LSM modules which have to
>> remain out-of-tree due to proposed-but-not-accepted by the upstream kernel.
>> This is a serious bug; is LSM a proprietary/closed code where modification is
>> impossible due to an End-User License Agreement?
> You are way off in the weeds with false equivalencies.
>
>> You have only three choices:
>>
>>  (1) allow assigning LSM ID integer value to all LSM modules (regardless of
>>      whether that module was merged into upstream kernel)
> We are not hardware manufacturers.
>
>>  (2) use module name string value as LSM ID
> This results is greater code complexity. If you see a way to do this, send a patch. Instead of unhelpfully saying "no, do it differently", show a solution.
>
>>  (3) dynamically assign LSM ID integer value when an LSM module is registered
> Again, send a patch.
>
>> There never is fourth choice:
>>
>>  (4) assigning LSM ID integer value to only LSM modules which were merged
>>      into upstream kernel
>>
>> The fourth choice is complete lockout of out of tree projects.
> This is just not a real outcome. How is this any different from syscalls, capability bits, prctl values, ELF flags, etc?
>
Loadability and the LSM ID are completely separate issues. Show me a patch
that implements loading modules and I will show you how to change it to
accommodate the LSM ID. That is, if it isn't obvious at that point.

Re: LSM stacking in next for 6.1?

[Tetsuo Handa]

On 2022/10/31 1:37, Kees Cook wrote:
>> You have only three choices:
>>
>>  (1) allow assigning LSM ID integer value to all LSM modules (regardless of
>>      whether that module was merged into upstream kernel)
> 
> We are not hardware manufacturers.
> 

Excuse me? We are not talking about whether we are hardware manufacturers.
We are talking about the policy for assigning identifier.

I don't like how LSM IDs are assigned, for Casey said

  >> If the upstream kernel assigns an LSM id for all LSM modules including out-of-tree
  >> and/or private LSM modules (that's why I described that the upstream kernel behaves
  >> as if a DNS registerer), we can assign LSM id = 100 to "belllapadula" from A and
  >> LSM id = 101 to "belllapadula" from B, and both "belllapadula" modules can work
  >> without conflicts by using LSM id. Of course, this implies that we need to preserve
  >> unused space in lsm_idlist[LSMID_ENTRIES] etc. for such LSM modules (if we use
  >> fixed-sized array rather than a linked list).
  > 
  > Of course the upstream kernel isn't going to have LSM IDs for out-of-tree
  > security modules. That's one of many reasons loadable modules are going to
  > have to be treated differently from built-in modules, if they're allowed
  > at all.

at https://lkml.kernel.org/r/7263e155-9024-0508-370c-72692901b326@schaufler-ca.com and
Paul confirmed

  >> Currently anyone can start writing new LSM modules using name as identifier. But
  >> you are trying to forbid using name as identifier, and trying to force using integer
  >> as identifier, but that integer will not be provided unless new LSM modules get
  >> upstream.
  > 
  > That is correct.  In order to have a LSM identifier token the LSM must
  > be upstream.

at https://lkml.kernel.org/r/CAHC9VhT2Azg1F-G3RQ4xL7JgA3OAtHafzS1_nvUyEUFsCJ9+SA@mail.gmail.com .

If we can agree that the upstream kernel never refuse to assign LSM IDs to whatever
LSM modules, I'm OK that we introduce LSM ID integer value itself.



My next concern is that we are trying to use fixed sized capacity as LSMID_ENTRIES,
commented

  On 2022/10/13 19:04, Tetsuo Handa wrote:
  > On 2022/09/28 4:53, Casey Schaufler wrote:
  >> +	if (lsm_id > LSMID_ENTRIES)
  >> +		panic("%s Too many LSMs registered.\n", __func__);
  > 
  > I'm not happy with LSMID_ENTRIES. This is a way towards forever forbidding LKM-based LSMs.

at https://lkml.kernel.org/r/9907d724-4668-cd50-7454-1a8ca86542b0@I-love.SAKURA.ne.jp , for

  struct lsm_id *lsm_idlist[LSMID_ENTRIES] __lsm_ro_after_init;

may cause out-of-tree LSM modules to fail to use the slot.

It is a strange hack that users have to enable in-tree LSM modules or rewrite the
definition of LSMID_ENTRIES in order to use out-of-tree (either built-in or loadable)
LSM modules, for LSMID_ENTRIES is defined based on only in-tree LSM modules.

  #define LSMID_ENTRIES ( \
        1 + /* capabilities */ \
        (IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
        (IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
        (IS_ENABLED(CONFIG_SECURITY_TOMOYO) ? 1 : 0) + \
        (IS_ENABLED(CONFIG_SECURITY_IMA) ? 1 : 0) + \
        (IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
        (IS_ENABLED(CONFIG_SECURITY_YAMA) ? 1 : 0) + \
        (IS_ENABLED(CONFIG_SECURITY_LOADPIN) ? 1 : 0) + \
        (IS_ENABLED(CONFIG_SECURITY_SAFESETID) ? 1 : 0) + \
        (IS_ENABLED(CONFIG_SECURITY_LOCKDOWN) ? 1 : 0) + \
        (IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0) + \
        (IS_ENABLED(CONFIG_SECURITY_LANDLOCK) ? 1 : 0))

Although built-in out-of-tree LSM modules would be able to rewrite LSMID_ENTRIES definition
because users will rebuild the whole kernel, loadable out-of-tree LSM modules would not be
able to rewrite LSMID_ENTRIES definition because users will not rebuild the whole kernel.
It is still effectively a lock out for loadable out-of-tree LSM modules even if the problem
of assigning LSM ID integer value is solved.

Re: LSM stacking in next for 6.1?

[Casey Schaufler]

On 10/31/2022 3:26 AM, Tetsuo Handa wrote:
> On 2022/10/31 1:37, Kees Cook wrote:
>>> You have only three choices:
>>>
>>>  (1) allow assigning LSM ID integer value to all LSM modules (regardless of
>>>      whether that module was merged into upstream kernel)
>> We are not hardware manufacturers.
>>
> Excuse me? We are not talking about whether we are hardware manufacturers.
> We are talking about the policy for assigning identifier.
>
> I don't like how LSM IDs are assigned, for Casey said
>
>   >> If the upstream kernel assigns an LSM id for all LSM modules including out-of-tree
>   >> and/or private LSM modules (that's why I described that the upstream kernel behaves
>   >> as if a DNS registerer), we can assign LSM id = 100 to "belllapadula" from A and
>   >> LSM id = 101 to "belllapadula" from B, and both "belllapadula" modules can work
>   >> without conflicts by using LSM id. Of course, this implies that we need to preserve
>   >> unused space in lsm_idlist[LSMID_ENTRIES] etc. for such LSM modules (if we use
>   >> fixed-sized array rather than a linked list).
>   > 
>   > Of course the upstream kernel isn't going to have LSM IDs for out-of-tree
>   > security modules. That's one of many reasons loadable modules are going to
>   > have to be treated differently from built-in modules, if they're allowed
>   > at all.
>
> at https://lkml.kernel.org/r/7263e155-9024-0508-370c-72692901b326@schaufler-ca.com and
> Paul confirmed
>
>   >> Currently anyone can start writing new LSM modules using name as identifier. But
>   >> you are trying to forbid using name as identifier, and trying to force using integer
>   >> as identifier, but that integer will not be provided unless new LSM modules get
>   >> upstream.
>   > 
>   > That is correct.  In order to have a LSM identifier token the LSM must
>   > be upstream.
>
> at https://lkml.kernel.org/r/CAHC9VhT2Azg1F-G3RQ4xL7JgA3OAtHafzS1_nvUyEUFsCJ9+SA@mail.gmail.com .
>
> If we can agree that the upstream kernel never refuse to assign LSM IDs to whatever
> LSM modules, I'm OK that we introduce LSM ID integer value itself.
>
>
>
> My next concern is that we are trying to use fixed sized capacity as LSMID_ENTRIES,
> commented
>
>   On 2022/10/13 19:04, Tetsuo Handa wrote:
>   > On 2022/09/28 4:53, Casey Schaufler wrote:
>   >> +	if (lsm_id > LSMID_ENTRIES)
>   >> +		panic("%s Too many LSMs registered.\n", __func__);
>   > 
>   > I'm not happy with LSMID_ENTRIES. This is a way towards forever forbidding LKM-based LSMs.
>
> at https://lkml.kernel.org/r/9907d724-4668-cd50-7454-1a8ca86542b0@I-love.SAKURA.ne.jp , for
>
>   struct lsm_id *lsm_idlist[LSMID_ENTRIES] __lsm_ro_after_init;
>
> may cause out-of-tree LSM modules to fail to use the slot.
>
> It is a strange hack that users have to enable in-tree LSM modules or rewrite the
> definition of LSMID_ENTRIES in order to use out-of-tree (either built-in or loadable)
> LSM modules, for LSMID_ENTRIES is defined based on only in-tree LSM modules.
>
>   #define LSMID_ENTRIES ( \
>         1 + /* capabilities */ \
>         (IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
>         (IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
>         (IS_ENABLED(CONFIG_SECURITY_TOMOYO) ? 1 : 0) + \
>         (IS_ENABLED(CONFIG_SECURITY_IMA) ? 1 : 0) + \
>         (IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
>         (IS_ENABLED(CONFIG_SECURITY_YAMA) ? 1 : 0) + \
>         (IS_ENABLED(CONFIG_SECURITY_LOADPIN) ? 1 : 0) + \
>         (IS_ENABLED(CONFIG_SECURITY_SAFESETID) ? 1 : 0) + \
>         (IS_ENABLED(CONFIG_SECURITY_LOCKDOWN) ? 1 : 0) + \
>         (IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0) + \
>         (IS_ENABLED(CONFIG_SECURITY_LANDLOCK) ? 1 : 0))
>
> Although built-in out-of-tree LSM modules would be able to rewrite LSMID_ENTRIES definition
> because users will rebuild the whole kernel, loadable out-of-tree LSM modules would not be
> able to rewrite LSMID_ENTRIES definition because users will not rebuild the whole kernel.
> It is still effectively a lock out for loadable out-of-tree LSM modules even if the problem
> of assigning LSM ID integer value is solved.

Propose an implementation of security module loading. If LSMID_ENTRIES is a problem
I will help you resolve the issue. My bet is that there will be an easy solution. It
may be as simple as adding (IS_ENABLED(CONFIG_SECURITY_LOADABLE) ? 1 : 0) + \ to the
code referenced above. But I can't say until I see how you're going to address all
of the real issues.

Re: LSM stacking in next for 6.1?

[Paul Moore]

On Tue, Oct 25, 2022 at 7:20 AM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> On 2022/10/25 19:26, John Johansen wrote:
> > no, Casey is not. He is trying to find a path forward to get LSM
> > stacking upstream sooner than later. He has made proposals that
> > admittedly you have not liked, but he has at least tried to propose
> > ideas that could work within the insane set of constraints.
>
> I'm OK with getting LSM stacking upstream. But changes made based on
> only built-in modules are bad. If LSM id cannot be assigned to loadable
> LSM modules at runtime because not all loadable LSM modules will be
> in-tree in order to get an LSM id assigned, loadable LSM modules won't
> be able to utilize e.g. lsm_module_list system call (or whatever
> changes made while trying to unshare resources/interfaces currently
> shared among SELinux/Smack/AppArmor).

As a reminder, the LSM layer, just like the rest of the kernel, has no
plans to provide any level of consideration or support for out-of-tree
kernel code.  LSMs which are not part of the upstream Linux kernel are
not our concern here; if they fail to work with the syscall and/or LSM
stacking changes merged, that should not be considered a blocker to
upstream development.

-- 
paul-moore.com

Re: LSM stacking in next for 6.1?

[Tetsuo Handa]

On 2022/10/27 5:11, Paul Moore wrote:
> On Tue, Oct 25, 2022 at 7:20 AM Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
>> On 2022/10/25 19:26, John Johansen wrote:
>>> no, Casey is not. He is trying to find a path forward to get LSM
>>> stacking upstream sooner than later. He has made proposals that
>>> admittedly you have not liked, but he has at least tried to propose
>>> ideas that could work within the insane set of constraints.
>>
>> I'm OK with getting LSM stacking upstream. But changes made based on
>> only built-in modules are bad. If LSM id cannot be assigned to loadable
>> LSM modules at runtime because not all loadable LSM modules will be
>> in-tree in order to get an LSM id assigned, loadable LSM modules won't
>> be able to utilize e.g. lsm_module_list system call (or whatever
>> changes made while trying to unshare resources/interfaces currently
>> shared among SELinux/Smack/AppArmor).
> 
> As a reminder, the LSM layer, just like the rest of the kernel, has no
> plans to provide any level of consideration or support for out-of-tree
> kernel code.  LSMs which are not part of the upstream Linux kernel are
> not our concern here; if they fail to work with the syscall and/or LSM
> stacking changes merged, that should not be considered a blocker to
> upstream development.
> 

No. You are misunderstanding. This problem is not limited to out-of-tree and/or
loadable LSM modules. This change prevents new LSM modules from getting upstream
due to a chicken-and-egg problem.

Currently anyone can start writing new LSM modules using name as identifier. But
you are trying to forbid using name as identifier, and trying to force using integer
as identifier, but that integer will not be provided unless new LSM modules get
upstream.

Then, how those who want to write new LSM modules can start writing LSM modules and
propose userspace changes for new LSM modules? They can't use the identifier unless
their LSM module get upstream, which in turn forces them not to propose interface for
userspace programs, which in turn makes it difficult to get new LSM modules tested
by users, which in turn makes it difficult to get upstream due to "who is using your
LSM module" question, which in turn makes it difficult to get the identifier...

You are trying to force CONFIG_MODULES=n by just "we don't care about out-of-tree code".
Trying to change identifier from name to integer is a serious bug.

Re: LSM stacking in next for 6.1?

[Paul Moore]

On Wed, Oct 26, 2022 at 8:02 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> On 2022/10/27 5:11, Paul Moore wrote:
> > On Tue, Oct 25, 2022 at 7:20 AM Tetsuo Handa
> > <penguin-kernel@i-love.sakura.ne.jp> wrote:
> >> On 2022/10/25 19:26, John Johansen wrote:
> >>> no, Casey is not. He is trying to find a path forward to get LSM
> >>> stacking upstream sooner than later. He has made proposals that
> >>> admittedly you have not liked, but he has at least tried to propose
> >>> ideas that could work within the insane set of constraints.
> >>
> >> I'm OK with getting LSM stacking upstream. But changes made based on
> >> only built-in modules are bad. If LSM id cannot be assigned to loadable
> >> LSM modules at runtime because not all loadable LSM modules will be
> >> in-tree in order to get an LSM id assigned, loadable LSM modules won't
> >> be able to utilize e.g. lsm_module_list system call (or whatever
> >> changes made while trying to unshare resources/interfaces currently
> >> shared among SELinux/Smack/AppArmor).
> >
> > As a reminder, the LSM layer, just like the rest of the kernel, has no
> > plans to provide any level of consideration or support for out-of-tree
> > kernel code.  LSMs which are not part of the upstream Linux kernel are
> > not our concern here; if they fail to work with the syscall and/or LSM
> > stacking changes merged, that should not be considered a blocker to
> > upstream development.
> >
>
> No. You are misunderstanding.

With all due respect, I understand your point very well, I'm simply
trying to explain to you the position that the Linux Kernel has
historically taken with respect to out-of-tree and in-development
code.

> This problem is not limited to out-of-tree and/or
> loadable LSM modules. This change prevents new LSM modules from getting upstream
> due to a chicken-and-egg problem.

It does *not* prevent new LSM modules from being merged upstream.

It may make it more difficult for out-of-tree modules to remain
out-of-tree, but that is both not a concern of the upstream community
nor is it the concern you are currently describing.

> Currently anyone can start writing new LSM modules using name as identifier. But
> you are trying to forbid using name as identifier, and trying to force using integer
> as identifier, but that integer will not be provided unless new LSM modules get
> upstream.

That is correct.  In order to have a LSM identifier token the LSM must
be upstream.

> Then, how those who want to write new LSM modules can start writing LSM modules and
> propose userspace changes for new LSM modules? They can't use the identifier unless
> their LSM module get upstream, which in turn forces them not to propose interface for
> userspace programs, which in turn makes it difficult to get new LSM modules tested
> by users, which in turn makes it difficult to get upstream due to "who is using your
> LSM module" question, which in turn makes it difficult to get the identifier...

First, new LSMs generally do not need extensive userspace
modifications; of course there may be some, but when one considers the
entirety of a modern Linux distribution the actual percentage should
be quite small.  In addition, it is not uncommon for in-development
LSMs to have a set of privately, i.e. not upstreamed, patched
userspace tools while the new LSM works to get upstream.  These
private userspace patches are generally merged after the LSM has been
merged into the kernel.

> You are trying to force CONFIG_MODULES=n by just "we don't care about out-of-tree code".

That is not the goal at all and I would appreciate it if you could
stop slandering the motivations of the LSM syscall effort.

> Trying to change identifier from name to integer is a serious bug.

I disagree.  One would have a similar problem - userspace
awareness/enablement - regardless of if a name or a token is used.
Ultimately the challenge is getting userspace developers to accept a
change that is not part of the upstream Linux Kernel and thus not
guaranteed under the usual "don't break userspace" kernel API promise.

-- 
paul-moore.com

Re: LSM stacking in next for 6.1?

[Tetsuo Handa]

On 2022/10/28 18:50, Paul Moore wrote:
>> This problem is not limited to out-of-tree and/or
>> loadable LSM modules. This change prevents new LSM modules from getting upstream
>> due to a chicken-and-egg problem.
> 
> It does *not* prevent new LSM modules from being merged upstream.
> 
> It may make it more difficult for out-of-tree modules to remain
> out-of-tree, but that is both not a concern of the upstream community
> nor is it the concern you are currently describing.

New LSM modules are out-of-tree modules until being merged upstream.

LSM modules is an area which is difficult to get merged upstream for
unknown reasons. You remember the label versus pathname war, don't you?
Do you remember that 10 modules were proposed 

    SimpleFlow ( 2016/04/21 https://lwn.net/Articles/684825/ )
    HardChroot ( 2016/07/29 https://lwn.net/Articles/695984/ )
    Checmate ( 2016/08/04 https://lwn.net/Articles/696344/ )
    LandLock ( 2016/08/25 https://lwn.net/Articles/698226/ )
    PTAGS ( 2016/09/29 https://lwn.net/Articles/702639/ )
    CaitSith ( 2016/10/21 https://lwn.net/Articles/704262/ )
    SafeName ( 2016/05/03 https://lwn.net/Articles/686021/ )
    WhiteEgret ( 2017/05/30 https://lwn.net/Articles/724192/ )
    shebang ( 2017/06/09 https://lwn.net/Articles/725285/ )
    S.A.R.A. ( 2017/06/13 https://lwn.net/Articles/725230/ )

and how many of them got merged upstream? It is inevitable that some
(or rather, many or most) of LSM modules cannot be merged upstream or
be enabled by distributors.

Even if perfect LSM stacking is implemented, I can imagine a future that
none of LSM modules available in upstream kernel can satisfy user's needs.
LSM stacking makes sense only if LSM modules which can satisfy user's needs
are available. And we know that upstream kernel won't accept whatever LSMs.

I consider /sbin/insmod-able LSM modules as a compromise/remedy for LSM modules
which could not get merged upstream or supported by distributors, for patching and
rebuilding the whole kernel in order to use not-yet-upstreamed and/or not-builtin
LSMs is already a lot of barrier for users. But requiring a permanent integer in
order to use a LSM module is a denial of even patching and rebuilding the whole
kernel. That's why I hate this change.

> 
>> Currently anyone can start writing new LSM modules using name as identifier. But
>> you are trying to forbid using name as identifier, and trying to force using integer
>> as identifier, but that integer will not be provided unless new LSM modules get
>> upstream.
> 
> That is correct.  In order to have a LSM identifier token the LSM must
> be upstream.

Then, new LSM modules which are intended to be merged upstream can't write
userspace interface.

> 
>> Then, how those who want to write new LSM modules can start writing LSM modules and
>> propose userspace changes for new LSM modules? They can't use the identifier unless
>> their LSM module get upstream, which in turn forces them not to propose interface for
>> userspace programs, which in turn makes it difficult to get new LSM modules tested
>> by users, which in turn makes it difficult to get upstream due to "who is using your
>> LSM module" question, which in turn makes it difficult to get the identifier...
> 
> First, new LSMs generally do not need extensive userspace
> modifications; of course there may be some, but when one considers the
> entirety of a modern Linux distribution the actual percentage should
> be quite small.

I agree that new LSMs generally do not need extensive userspace modifications.
But

>                  In addition, it is not uncommon for in-development
> LSMs to have a set of privately, i.e. not upstreamed, patched
> userspace tools while the new LSM works to get upstream.  These
> private userspace patches are generally merged after the LSM has been
> merged into the kernel.

I still think an identifier is needed when developing management programs for each
new LSM.

Do you mean that management programs which are specific to each LSM module are not
forced to use the identifier Casey is trying to introduce? If yes, why does "you are
trying to forbid using name as identifier, and trying to force using integer as
identifier" need to be correct? Only programs that do not belong to specific LSM
module but needs to be able to recognize various LSM modules' per task attributes
need to use the identifier Casey is trying to introduce.

I can't understand why assigning a permanent integer identifier is mandatory.
TOMOYO (and trivial LSMs) will not need such identifier. This change merely makes
it more difficult to stack minor/trivial LSMs implemented as /sbin/insmod-able LSMs,
by introducing fixed sized array.

> 
>> You are trying to force CONFIG_MODULES=n by just "we don't care about out-of-tree code".
> 
> That is not the goal at all and I would appreciate it if you could
> stop slandering the motivations of the LSM syscall effort.
> 
>> Trying to change identifier from name to integer is a serious bug.
> 
> I disagree.  One would have a similar problem - userspace
> awareness/enablement - regardless of if a name or a token is used.

TOMOYO (and trivial LSMs) will not need userspace awareness/enablement.

> Ultimately the challenge is getting userspace developers to accept a
> change that is not part of the upstream Linux Kernel and thus not
> guaranteed under the usual "don't break userspace" kernel API promise.

I'm not against the challenge. But none of "introducing fixed sized array",
"assigning permanent integer for the fixed sized array", "not assigning permanent
integer unless merged upstream" is required for achieving the challenge. We can
achieve the challenge via "using linked list" and "using name or assigning dynamic
integer upon loading of a LSM module". (Of course, if upstream kernel allows assigning
permanent integer before getting merged, we can use integer for the userspace...)

Re: LSM stacking in next for 6.1?

[Kees Cook]

On Fri, Oct 28, 2022 at 10:58:30PM +0900, Tetsuo Handa wrote:
> Do you remember that 10 modules were proposed 
> 
>     SimpleFlow ( 2016/04/21 https://lwn.net/Articles/684825/ )
>     HardChroot ( 2016/07/29 https://lwn.net/Articles/695984/ )
>     Checmate ( 2016/08/04 https://lwn.net/Articles/696344/ )
>     LandLock ( 2016/08/25 https://lwn.net/Articles/698226/ )
>     PTAGS ( 2016/09/29 https://lwn.net/Articles/702639/ )
>     CaitSith ( 2016/10/21 https://lwn.net/Articles/704262/ )
>     SafeName ( 2016/05/03 https://lwn.net/Articles/686021/ )
>     WhiteEgret ( 2017/05/30 https://lwn.net/Articles/724192/ )
>     shebang ( 2017/06/09 https://lwn.net/Articles/725285/ )
>     S.A.R.A. ( 2017/06/13 https://lwn.net/Articles/725230/ )

There was also:

      LoadPin ( 2016/04/20 https://lore.kernel.org/lkml/1461192388-13900-1-git-send-email-keescook@chromium.org/ )
      SafeSetID ( 2018/10/31 https://lore.kernel.org/linux-security-module/20181031152846.234791-1-mortonm@chromium.org/ )
      BPF ( 2019/09/10 https://lore.kernel.org/linux-security-module/20190910115527.5235-1-kpsingh@chromium.org/ )

So, 13 LSM proposed, 4 landed: roughly 30%, which is on par[1] with regular
kernel development.

> I consider /sbin/insmod-able LSM modules as a compromise/remedy for LSM modules
> which could not get merged upstream or supported by distributors, for patching and
> rebuilding the whole kernel in order to use not-yet-upstreamed and/or not-builtin
> LSMs is already a lot of barrier for users. But requiring a permanent integer in
> order to use a LSM module is a denial of even patching and rebuilding the whole
> kernel. That's why I hate this change.

But the upstream kernel _does not support APIs for out-of-tree code_. To
that point, security_add_hooks() is _not exported_, so it is already not
possible to create a modular LSM without patching the kernel source.

> I can't understand why assigning a permanent integer identifier is mandatory.

Plenty of other APIs use numeric identifiers: syscalls, prctl, etc. This
doesn't block them from being upstreamed.

-Kees

[1] https://ieeexplore.ieee.org/abstract/document/6624016

-- 
Kees Cook

Re: LSM stacking in next for 6.1?

[Tetsuo Handa]

On 2022/10/29 2:40, Kees Cook wrote:
> On Fri, Oct 28, 2022 at 10:58:30PM +0900, Tetsuo Handa wrote:
>> I consider /sbin/insmod-able LSM modules as a compromise/remedy for LSM modules
>> which could not get merged upstream or supported by distributors, for patching and
>> rebuilding the whole kernel in order to use not-yet-upstreamed and/or not-builtin
>> LSMs is already a lot of barrier for users. But requiring a permanent integer in
>> order to use a LSM module is a denial of even patching and rebuilding the whole
>> kernel. That's why I hate this change.
> 
> But the upstream kernel _does not support APIs for out-of-tree code_. To
> that point, security_add_hooks() is _not exported_, so it is already not
> possible to create a modular LSM without patching the kernel source.

AKARI/CaitSith and several other LSM modules are running without patching
the kernel source. But this patchset makes it impossible to use 9 out of 13
LSM modules as (not upstreamed but) built-in LSM modules by patching the kernel,
due to lack of identifier. That's a needless requirement that harms development
of LSM modules.

Linux kernel has started using a new and more inclusive terminology for the
Linux kernel code and documentation. But this patchset is making the code
more and more exclusive. That's a way to exclude LSM modules that satisfies
user's need, even if perfect LSM stacking implementation is provided.

What do you think if an authority commands you that companies like Intel, Google,
RedHat, Canonical etc. must wind up because these companies are not member of
that authority? That's behavior of autocracy.

This patchset _does not allow out-of-tree code to exist_ rather than simply
_does not support APIs for out-of-tree code_. The behavior of this patchset is
to exclude 9 out of 13 LSM modules, unless upstream kernel allows these modules
to exist (by assigning an LSM id value). What a closed community LSM is!

Re: LSM stacking in next for 6.1?

[Paul Moore]

On Thu, Sep 8, 2022 at 6:56 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> I am going to start playing with these syscalls. Please help me understand
> where I have suggested something stoopid.

Thanks for posting an initial patch that we can use for further
discussion.  Time is a bit tight this week due to LPC/LSS-EU so I'm
not sure I'll have the time to provide any meaningful comments, but if
nothing else it's on my todo list for next week.

-- 
paul-moore.com

Re: LSM stacking in next for 6.1?

[Casey Schaufler]

On 9/14/2022 6:42 AM, Paul Moore wrote:
> On Thu, Sep 8, 2022 at 6:56 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> I am going to start playing with these syscalls. Please help me understand
>> where I have suggested something stoopid.
> Thanks for posting an initial patch that we can use for further
> discussion.  Time is a bit tight this week due to LPC/LSS-EU so I'm
> not sure I'll have the time to provide any meaningful comments, but if
> nothing else it's on my todo list for next week.

With a full understanding that the 6.1 boat has not only sailed but has
subsequently been sunk by pirates I've posted my v38 stacking patches.
I would have liked to wait for some amount of "discussion" on the proposed
syscalls and prctl() options before posting, but it seems that isn't
going to happen on its own. In spite of the radical change to the user
interface I am pushing for -next for 6.2. If there has to be discussion
about the interface we should have it. I'm going to be (mostly) off line
the first half of October, and was seriously hoping to have any issues
identified before then. If that can't happen I need some idea what can
make it happen on some sort of timeline.

Re: LSM stacking in next for 6.1?

[Paul Moore]

On Tue, Sep 27, 2022 at 4:54 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> On 9/14/2022 6:42 AM, Paul Moore wrote:
> > On Thu, Sep 8, 2022 at 6:56 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >> I am going to start playing with these syscalls. Please help me understand
> >> where I have suggested something stoopid.
> > Thanks for posting an initial patch that we can use for further
> > discussion.  Time is a bit tight this week due to LPC/LSS-EU so I'm
> > not sure I'll have the time to provide any meaningful comments, but if
> > nothing else it's on my todo list for next week.
>
> With a full understanding that the 6.1 boat has not only sailed but has
> subsequently been sunk by pirates I've posted my v38 stacking patches.
> I would have liked to wait for some amount of "discussion" on the proposed
> syscalls and prctl() options before posting, but it seems that isn't
> going to happen on its own ...

I was happy to see the patches posted, and they are in my queue, but
being away the week of LPC/LSS-EU as well as some other more near-term
patchsets that need review have delayed my ability to review your
syscall patches.

-- 
paul-moore.com

Re: LSM stacking in next for 6.1?

[Casey Schaufler]

On 9/6/2022 4:24 PM, Paul Moore wrote:
> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@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.
>> This is a compound problem. Some applications, including systemd and dbus,
>> will require modification to completely support multiple concurrent LSMs
>> in the long term. This will certainly be the case should someone be wild
>> and crazy enough to use Smack and SELinux together. Even with the (Smack or
>> SELinux) and AppArmor case the ps(1) command should be educated about the
>> possibility of multiple "current" values. However, in a container world,
>> where an Android container can run on an Ubuntu system, the presence of
>> AppArmor on the base system is completely uninteresting to the SELinux
>> aware applications in the container. This is a real use case.
> If you are running AppArmor on the host system and SELinux in a
> container you are likely going to have some *very* bizarre behavior as
> the SELinux policy you load in the container will apply to the entire
> system, including processes which started *before* the SELinux policy
> was loaded.  While I understand the point you are trying to make, I
> don't believe the example you chose is going to work without a lot of
> other changes.

I don't use it myself, but I know it's frighteningly popular.

> Regardless of the above example, I want to be clear that I'm not
> suggesting changes to the /proc interfaces.  Existing LSM aware
> applications that use procfs for information would continue to work as
> expected, it would just be the simul-multi-LSM aware applications that
> would need to transition to the new syscall API to get all of the LSM
> labels.

They're going to have to do something, true enough.

>>> I think it's time to think about a proper set of LSM syscalls.
>> At the very least we need a liblsm that preforms a number of useful
>> functions, like identifying what security modules are available,
>> validating "contexts", fetching "contexts" from files and processes
>> and that sort of thing. Whether it is built on syscalls or /proc and
>> getxattr() is a matter of debate and taste.
> Why is it a forgone conclusion that a library would be necessary for
> basic operations?  If the kernel/userspace API is sane to begin with
> we could probably either significantly reduce or eliminate the need
> for additional libraries.

I'm using my experience with the "hideous" context format
( "apparmor\0unconfined\0smack\0User\0" ) as a guide. Creating
a "sane" API for returning multiple lsm/context pairs is going
to be tricky. No one wants to require iterative calls to get a
collection of values for example. I've spent the past few years
trying to pound out APIs that are somewhat sane. I don't want to
spend another few years repeating the process for kernel APIs.

>   I really want us to attempt to come up with
> a decent kernel/userspace API to begin with

That's fine, except that the process here is nowhere near the
beginning. v1 was in June of 2019, and I had posted several unnumbered
versions before then. No one has ever - not once - proposed syscall
interfaces until now. I would be delighted to investigate and include
syscall interfaces for the Complete stacking (SELinux + Smack) work,
as I can see considerably greater need for them there.

>  as opposed to using the
> excuse of a userspace library to hide API sins that never should have
> been committed.

I confess to having committed many hideous API sins.

> The LSM stacking work presents us with a unique opportunity to
> modify/update/whatever the LSM kernel/userspace API, I don't want to
> see us squander this chance on a hack.

I'm listening ...

>
>>> 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.
>> You can't script syscalls.
> True.  However I don't see that as a blocker, trivial helper
> applications can be written for those who wish to incorporate the new
> syscall-based API into their scripts.  We would not be the first (or
> the last) in this regard.

Trivial wrappers to set attributes aren't any cleaner than /proc interfaces.
And in any case, if you've hidden the syscall in a wrapper you can hide the
/proc interfaces in a wrapper as well.

>> A syscall interface is fine if you can also
>> update the entire system service application base for your distribution.
>> I don't see that as an option.
> Once again, I'm not talking about removing the existing procfs
> interface; existing applications would continue to work.  Only
> applications which wanted to be simul-multi-LSM aware would need to be
> modified, and those applications would need to be modified regardless
> of if the procfs or syscall-based API was used.

O..K.. then syscalls could be a completely separate project. 
The current work need not be dependent on whatever syscall work is done.


>>> Further, I think we can add the new syscall API separately from the
>>> LSM stacking changes as they do have standalone value.
>> I agree, but unless the new system calls take stacking into account
>> from their inception they're just going to be another interface that
>> makes stacking harder to accomplish.
> They obviously would Casey, not only is that the context of the
> discussion but my dummy example clearly had support for multiple LSMs.
>
>>>   This would
>>> help reduce the size and complexity of the stacking patchset, which I
>>> believe would be a very good thing.
>> The /proc interfaces interface_lsm and context are really pretty simple.
> They are now, they are also a bit of a mess with legacy constraints
> and they only get more complicated and messy with the LSM stacking
> patches.  It is my opinion that a syscall-based API is cleaner and
> easier for applications to use.

Yes. A syscall is easier for an application to use. A /proc interface
is much easier for a scripted system. The scripts are much more frequently
updated than the C coded services. Some of the services are so rarely and
cautiously updated that expecting them to be modernized is unreasonable.
How many system services use capabilities the way they were designed to
be used?

>
>> The addition of multiple subject labels to audit would be the same regardless
>> of /proc or syscall interfaces.
> Yes, that's why I didn't bring up audit as it doesn't weigh on this
> decision.  If you really want to include audit for some reason, I'll
> simply remind you that I pushed back hard on overloading the existing
> subj/obj fields with a multiplexed label format, asking for individual
> subj/obj fields for each LSM.

Just pointing out that the stacking patches aren't that complicated.

>
>> We'd still need multiple LSM data in most
>> security blobs. The conversion of LSM hook interfaces from secids to lsmblobs
>> would still be required. As would the conversion from string+len pairs to
>> lsmcontext structures.
> I'm not talking about kernel internal data structures Casey, I'm
> talking about the kernel/userspace API.

Again, just saying the the patches, while extensive, don't do very much
that's complicated.

>
>>> 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.
>> A liblsm based on the /proc interfaces would address that as well.
> Perhaps a liblsm library would be useful for other reasons beyond this
> discussion, but I don't want to use a userspace library as an excuse
> to support an awful kernel/userspace API.

What API are you saying is awful, and how would you improve it?
The sample APIs you proposed wouldn't work as syscalls.

>
>>> Thoughts?
>> I wish you'd suggested this three years ago, when I could have done
>> something with it. If stacking has to go on a two year redesign because
>> of this it is dead.
> I've never liked the combined label interfaces, see the mention of
> audit in this email above.  I'm sure if you wanted to dig through all
> of the mail archives I'm sure I've probably mentioned my dislike of
> the combined label interface in procfs too; if not on the mailing list
> then surely in-person at some point.  However, regardless of all that,
> the key difference is that prior to a few months ago I didn't have to
> worry about it quite as much as I do now.  Now I'm responsible for
> standing up for the code that goes into the LSM tree and that means
> both defending it as "good" and maintaining it long term; prior to a
> few months ago that was, politely, "not my problem" :)

Message received.

>
> I can't currently in good conscience defend the kernel/userspace
> combined label interfaces as "good", especially when we have a very
> rare opportunity to do better.

OK, so what interfaces need to be redone? I have been polishing what's
just become a turd for a %^&*(ing long time. I need to know whether it
is something I can address, or whether I just toss the entire thing in
the proverbial bit bucket.

Grumble grumble grumble.


 

Re: LSM stacking in next for 6.1?

[Paul Moore]

On Tue, Sep 6, 2022 at 8:31 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 9/6/2022 4:24 PM, Paul Moore wrote:
> > On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >> On 9/2/2022 2:30 PM, Paul Moore wrote:
> >>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
> >>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@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.
> >> This is a compound problem. Some applications, including systemd and dbus,
> >> will require modification to completely support multiple concurrent LSMs
> >> in the long term. This will certainly be the case should someone be wild
> >> and crazy enough to use Smack and SELinux together. Even with the (Smack or
> >> SELinux) and AppArmor case the ps(1) command should be educated about the
> >> possibility of multiple "current" values. However, in a container world,
> >> where an Android container can run on an Ubuntu system, the presence of
> >> AppArmor on the base system is completely uninteresting to the SELinux
> >> aware applications in the container. This is a real use case.
> > If you are running AppArmor on the host system and SELinux in a
> > container you are likely going to have some *very* bizarre behavior as
> > the SELinux policy you load in the container will apply to the entire
> > system, including processes which started *before* the SELinux policy
> > was loaded.  While I understand the point you are trying to make, I
> > don't believe the example you chose is going to work without a lot of
> > other changes.
>
> I don't use it myself, but I know it's frighteningly popular.

All right, I'm going to call your bluff here - who are these people
running AppArmor on the host and SELinux in a container?  What policy
are they using, it's surely not an unmodified Fedora/RHEL or upstream
refpol policy?  Do they run in enforcing mode without massive
permissions granted to kernel_t (I'm guessing all of the host
applications would appear as kernel_t)?  How do you handle multiple
SELinux containers?

I'm aware of *one* use case where SELinux is run in a container and
that required a number of careful constraints on the use case and a
good deal of hacking to enable.  I'm sure there are definitely people
that *want* this, especially in the context of Ubuntu, but I really
doubt this is in widespread use today.

> >>> I think it's time to think about a proper set of LSM syscalls.
> >> At the very least we need a liblsm that preforms a number of useful
> >> functions, like identifying what security modules are available,
> >> validating "contexts", fetching "contexts" from files and processes
> >> and that sort of thing. Whether it is built on syscalls or /proc and
> >> getxattr() is a matter of debate and taste.
> > Why is it a forgone conclusion that a library would be necessary for
> > basic operations?  If the kernel/userspace API is sane to begin with
> > we could probably either significantly reduce or eliminate the need
> > for additional libraries.
>
> I'm using my experience with the "hideous" context format
> ( "apparmor\0unconfined\0smack\0User\0" ) as a guide. Creating
> a "sane" API for returning multiple lsm/context pairs is going
> to be tricky. No one wants to require iterative calls to get a
> collection of values for example. I've spent the past few years
> trying to pound out APIs that are somewhat sane. I don't want to
> spend another few years repeating the process for kernel APIs.

See my earlier comment to John.  I care a lot about getting things
right, and very little about how long it takes.  I'm sympathetic about
the time and difficulty involved, but I see that as no reason to merge
a not-good design.

> >> The addition of multiple subject labels to audit would be the same regardless
> >> of /proc or syscall interfaces.
> >
> > Yes, that's why I didn't bring up audit as it doesn't weigh on this
> > decision.  If you really want to include audit for some reason, I'll
> > simply remind you that I pushed back hard on overloading the existing
> > subj/obj fields with a multiplexed label format, asking for individual
> > subj/obj fields for each LSM.
>
> Just pointing out that the stacking patches aren't that complicated.

Ha!  Let's just agree to disagree on that point :)

-- 
paul-moore.com

Re: LSM stacking in next for 6.1?

[Casey Schaufler]

On 9/7/2022 8:13 AM, Paul Moore wrote:
> On Tue, Sep 6, 2022 at 8:31 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/6/2022 4:24 PM, Paul Moore wrote:
>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@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.
>>>> This is a compound problem. Some applications, including systemd and dbus,
>>>> will require modification to completely support multiple concurrent LSMs
>>>> in the long term. This will certainly be the case should someone be wild
>>>> and crazy enough to use Smack and SELinux together. Even with the (Smack or
>>>> SELinux) and AppArmor case the ps(1) command should be educated about the
>>>> possibility of multiple "current" values. However, in a container world,
>>>> where an Android container can run on an Ubuntu system, the presence of
>>>> AppArmor on the base system is completely uninteresting to the SELinux
>>>> aware applications in the container. This is a real use case.
>>> If you are running AppArmor on the host system and SELinux in a
>>> container you are likely going to have some *very* bizarre behavior as
>>> the SELinux policy you load in the container will apply to the entire
>>> system, including processes which started *before* the SELinux policy
>>> was loaded.  While I understand the point you are trying to make, I
>>> don't believe the example you chose is going to work without a lot of
>>> other changes.
>> I don't use it myself, but I know it's frighteningly popular.
> All right, I'm going to call your bluff here - who are these people
> running AppArmor on the host and SELinux in a container?  What policy
> are they using, it's surely not an unmodified Fedora/RHEL or upstream
> refpol policy?  Do they run in enforcing mode without massive
> permissions granted to kernel_t (I'm guessing all of the host
> applications would appear as kernel_t)?  How do you handle multiple
> SELinux containers?

Beats me. All that SELinux policy stuff is over my head. ;)

Seriously, once they got the stacking patches applied they thanked
me for the help and disappeared until they decided to update the
kernel version and asked for help with the next round of patches.
They told me what they wanted to do, which was to run Android in
a container, but how they accomplished it was a set of details they
didn't share. I assume that you are right that they had to do
horrible things to either AppArmor or SELinux policy, or maybe both.
I also assume they wanted this as an environment to develop Android
applications, and may not have cared much about actual enforcement.
But they are happy users.

> I'm aware of *one* use case where SELinux is run in a container and
> that required a number of careful constraints on the use case and a
> good deal of hacking to enable.  I'm sure there are definitely people
> that *want* this, especially in the context of Ubuntu, but I really
> doubt this is in widespread use today.

What I know is that there is a community out there using it. I think
you're right that the way they're using it would be displeasing to
most of us.


>>>>> I think it's time to think about a proper set of LSM syscalls.
>>>> At the very least we need a liblsm that preforms a number of useful
>>>> functions, like identifying what security modules are available,
>>>> validating "contexts", fetching "contexts" from files and processes
>>>> and that sort of thing. Whether it is built on syscalls or /proc and
>>>> getxattr() is a matter of debate and taste.
>>> Why is it a forgone conclusion that a library would be necessary for
>>> basic operations?  If the kernel/userspace API is sane to begin with
>>> we could probably either significantly reduce or eliminate the need
>>> for additional libraries.
>> I'm using my experience with the "hideous" context format
>> ( "apparmor\0unconfined\0smack\0User\0" ) as a guide. Creating
>> a "sane" API for returning multiple lsm/context pairs is going
>> to be tricky. No one wants to require iterative calls to get a
>> collection of values for example. I've spent the past few years
>> trying to pound out APIs that are somewhat sane. I don't want to
>> spend another few years repeating the process for kernel APIs.
> See my earlier comment to John.  I care a lot about getting things
> right, and very little about how long it takes.  I'm sympathetic about
> the time and difficulty involved, but I see that as no reason to merge
> a not-good design.
>
>>>> The addition of multiple subject labels to audit would be the same regardless
>>>> of /proc or syscall interfaces.
>>> Yes, that's why I didn't bring up audit as it doesn't weigh on this
>>> decision.  If you really want to include audit for some reason, I'll
>>> simply remind you that I pushed back hard on overloading the existing
>>> subj/obj fields with a multiplexed label format, asking for individual
>>> subj/obj fields for each LSM.
>> Just pointing out that the stacking patches aren't that complicated.
> Ha!  Let's just agree to disagree on that point :)

OK, they're a teeny bit extensive. 

Re: LSM stacking in next for 6.1?

[Paul Moore]

On Wed, Sep 7, 2022 at 1:08 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 9/7/2022 8:13 AM, Paul Moore wrote:
> > On Tue, Sep 6, 2022 at 8:31 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >> On 9/6/2022 4:24 PM, Paul Moore wrote:
> >>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
> >>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
> >>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@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.
> >>>> This is a compound problem. Some applications, including systemd and dbus,
> >>>> will require modification to completely support multiple concurrent LSMs
> >>>> in the long term. This will certainly be the case should someone be wild
> >>>> and crazy enough to use Smack and SELinux together. Even with the (Smack or
> >>>> SELinux) and AppArmor case the ps(1) command should be educated about the
> >>>> possibility of multiple "current" values. However, in a container world,
> >>>> where an Android container can run on an Ubuntu system, the presence of
> >>>> AppArmor on the base system is completely uninteresting to the SELinux
> >>>> aware applications in the container. This is a real use case.
> >>> If you are running AppArmor on the host system and SELinux in a
> >>> container you are likely going to have some *very* bizarre behavior as
> >>> the SELinux policy you load in the container will apply to the entire
> >>> system, including processes which started *before* the SELinux policy
> >>> was loaded.  While I understand the point you are trying to make, I
> >>> don't believe the example you chose is going to work without a lot of
> >>> other changes.
> >> I don't use it myself, but I know it's frighteningly popular.
> > All right, I'm going to call your bluff here - who are these people
> > running AppArmor on the host and SELinux in a container?  What policy
> > are they using, it's surely not an unmodified Fedora/RHEL or upstream
> > refpol policy?  Do they run in enforcing mode without massive
> > permissions granted to kernel_t (I'm guessing all of the host
> > applications would appear as kernel_t)?  How do you handle multiple
> > SELinux containers?
>
> Beats me. All that SELinux policy stuff is over my head. ;)
>
> Seriously, once they got the stacking patches applied they thanked
> me for the help and disappeared until they decided to update the
> kernel version and asked for help with the next round of patches.
> They told me what they wanted to do, which was to run Android in
> a container, but how they accomplished it was a set of details they
> didn't share. I assume that you are right that they had to do
> horrible things to either AppArmor or SELinux policy, or maybe both.
> I also assume they wanted this as an environment to develop Android
> applications, and may not have cared much about actual enforcement.
> But they are happy users.
>
> > I'm aware of *one* use case where SELinux is run in a container and
> > that required a number of careful constraints on the use case and a
> > good deal of hacking to enable.  I'm sure there are definitely people
> > that *want* this, especially in the context of Ubuntu, but I really
> > doubt this is in widespread use today.
>
> What I know is that there is a community out there using it. I think
> you're right that the way they're using it would be displeasing to
> most of us.

Based on other comments in this thread it doesn't appear that there is
anyone using it, or at least not a significant percentage of users.  I
get that sometimes we need to interpolate/extrapolate a bit to
understand what users are actually doing, especially with certain
security-focused users, but I think you extrapolated (or assumed) a
bit too much in this case.  Please be more clear when you are
speculating in the future, there may be folks reading these mailing
lists that don't have the background or understanding to tell
assumptions from actual truth.

-- 
paul-moore.com

Re: LSM stacking in next for 6.1?

[Casey Schaufler]

On 9/7/2022 4:04 PM, Paul Moore wrote:
> On Wed, Sep 7, 2022 at 1:08 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/7/2022 8:13 AM, Paul Moore wrote:
>>> On Tue, Sep 6, 2022 at 8:31 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>> On 9/6/2022 4:24 PM, Paul Moore wrote:
>>>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@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.
>>>>>> This is a compound problem. Some applications, including systemd and dbus,
>>>>>> will require modification to completely support multiple concurrent LSMs
>>>>>> in the long term. This will certainly be the case should someone be wild
>>>>>> and crazy enough to use Smack and SELinux together. Even with the (Smack or
>>>>>> SELinux) and AppArmor case the ps(1) command should be educated about the
>>>>>> possibility of multiple "current" values. However, in a container world,
>>>>>> where an Android container can run on an Ubuntu system, the presence of
>>>>>> AppArmor on the base system is completely uninteresting to the SELinux
>>>>>> aware applications in the container. This is a real use case.
>>>>> If you are running AppArmor on the host system and SELinux in a
>>>>> container you are likely going to have some *very* bizarre behavior as
>>>>> the SELinux policy you load in the container will apply to the entire
>>>>> system, including processes which started *before* the SELinux policy
>>>>> was loaded.  While I understand the point you are trying to make, I
>>>>> don't believe the example you chose is going to work without a lot of
>>>>> other changes.
>>>> I don't use it myself, but I know it's frighteningly popular.
>>> All right, I'm going to call your bluff here - who are these people
>>> running AppArmor on the host and SELinux in a container?  What policy
>>> are they using, it's surely not an unmodified Fedora/RHEL or upstream
>>> refpol policy?  Do they run in enforcing mode without massive
>>> permissions granted to kernel_t (I'm guessing all of the host
>>> applications would appear as kernel_t)?  How do you handle multiple
>>> SELinux containers?
>> Beats me. All that SELinux policy stuff is over my head. ;)
>>
>> Seriously, once they got the stacking patches applied they thanked
>> me for the help and disappeared until they decided to update the
>> kernel version and asked for help with the next round of patches.
>> They told me what they wanted to do, which was to run Android in
>> a container, but how they accomplished it was a set of details they
>> didn't share. I assume that you are right that they had to do
>> horrible things to either AppArmor or SELinux policy, or maybe both.
>> I also assume they wanted this as an environment to develop Android
>> applications, and may not have cared much about actual enforcement.
>> But they are happy users.
>>
>>> I'm aware of *one* use case where SELinux is run in a container and
>>> that required a number of careful constraints on the use case and a
>>> good deal of hacking to enable.  I'm sure there are definitely people
>>> that *want* this, especially in the context of Ubuntu, but I really
>>> doubt this is in widespread use today.
>> What I know is that there is a community out there using it. I think
>> you're right that the way they're using it would be displeasing to
>> most of us.
> Based on other comments in this thread it doesn't appear that there is
> anyone using it,

Let's just discard that use case then.

>  or at least not a significant percentage of users.

Sure.

>   I
> get that sometimes we need to interpolate/extrapolate a bit to
> understand what users are actually doing, especially with certain
> security-focused users, but I think you extrapolated (or assumed) a
> bit too much in this case.

Let's just assume that.

>   Please be more clear when you are
> speculating in the future, there may be folks reading these mailing
> lists that don't have the background or understanding to tell
> assumptions from actual truth.

I erred in siting an example for which I am not positioned to provide
backup detail. My bad.

Re: LSM stacking in next for 6.1?

[Tetsuo Handa]

On 2022/08/03 9:01, Casey Schaufler 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.
> 

After ((SELinux xor Smack) and AppArmor) is made possible in next for 6.1, what
comes next? Are you planning to make (SELinux and Smack and AppArmor) possible?

My concern is, when loadable LSM modules becomes legal, for I'm refraining from
again proposing CaitSith until LSM stacking completes.

Linus Torvalds said

  You security people are insane. I'm tired of this "only my version is correct" crap.

at https://lkml.kernel.org/r/alpine.LFD.0.999.0710010803280.3579@woody.linux-foundation.org .

Many modules

    SimpleFlow （ 2016/04/21 https://lwn.net/Articles/684825/ ）
    HardChroot （ 2016/07/29 https://lwn.net/Articles/695984/ ）
    Checmate （ 2016/08/04 https://lwn.net/Articles/696344/ ）
    LandLock （ 2016/08/25 https://lwn.net/Articles/698226/ ）
    PTAGS （ 2016/09/29 https://lwn.net/Articles/702639/ ）
    CaitSith （ 2016/10/21 https://lwn.net/Articles/704262/ ）
    SafeName （ 2016/05/03 https://lwn.net/Articles/686021/ ）
    WhiteEgret （ 2017/05/30 https://lwn.net/Articles/724192/ ）
    shebang （ 2017/06/09 https://lwn.net/Articles/725285/ ）
    S.A.R.A. （ 2017/06/13 https://lwn.net/Articles/725230/ ）

are proposed 5 or 6 years ago, but mostly became silent...

I still need byte-code analysis for finding the hook and code for making the hook
writable in AKARI/CaitSith due to lack of EXPORT_SYMBOL_GPL(security_add_hooks).
I wonder when I can stop questions like https://osdn.net/projects/tomoyo/lists/archive/users-en/2022-September/000740.html
caused by https://patchwork.kernel.org/project/linux-security-module/patch/alpine.LRH.2.20.1702131631490.8914@namei.org/ .

Last 10 years, my involvement with Linux kernel is "fixing bugs" rather than
"developing security mechanisms". Changes what I found in the past 10 years are:

  As far as I'm aware, more than 99% of systems still disable SELinux. People use RHEL,
  but the reason to choose RHEL is not because RHEL supports SELinux. The only thing
  changed is that the way to disable SELinux changed from SELINUX=disabled in
  /etc/selinux/config to selinux=0 on kernel command line options.

  Instead, Ubuntu users are increasing, but the reason people choose Ubuntu is not because
  Ubuntu supports AppArmor. Maybe because easy to use container environment. Maybe because
  available as Windows Subsystem for Linux.

  However, in many cases, it seems that whether the OS is Windows or Linux no longer
  matters. Programs are written using frameworks/languages which developers hardly care
  about Windows API or Linux syscall. LSM significantly focuses on syscalls, but the
  trend might no longer be trying to solve in the LSM layer...

Also, Linux servers started using AntiVirus software. Enterprise AntiVirus software uses
loadable kernel module that rewrites system call table rather than using LSM interface.
It seems that people prefer out-of-the-box security over fine grained access control rule
based security. In other words, it seems that allowlist based LSM modules are too
difficult for normal users. Maybe it is better for normal users to develop and use
single-function LSMs than try to utilize ((SELinux xor Smack) and AppArmor)... But
still loadable LSM modules are not legally available...

Re: LSM stacking in next for 6.1?

[Casey Schaufler]

On 9/8/2022 8:18 AM, Tetsuo Handa wrote:
> On 2022/08/03 9:01, Casey Schaufler 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.
>>
> After ((SELinux xor Smack) and AppArmor) is made possible in next for 6.1, what
> comes next? Are you planning to make (SELinux and Smack and AppArmor) possible?

The stacking isn't going into 6.1. Paul's decision that LSM system calls are
a requirement will require additional work. With LSS-EU next week and a long
overdue trip on my part in early October I don't see 6.2 as at all likely, either.

The commitment I made to Paul some years ago now was that the stacking would
eventually include making all combinations possible. That is still my plan.
The issues beyond ((SELinux xor Smack) and AppArmor) are primarily network
related. Secmarks, netlabel and SO_PEERSEC in particular. I have posted
preliminary patches in the past, but they need to be revisited in light of
development that has occurred since then.

On the other hand, I'm getting the "when are you going to retire?" question
way way way too regularly these days. While I intend to complete the work as
promised, I don't expect to be working on much with significant importance
come 2030.

> My concern is, when loadable LSM modules becomes legal, for I'm refraining from
> again proposing CaitSith until LSM stacking completes.

I would not wait. There is no reason the efforts cannot progress in parallel.

> Linus Torvalds said
>
>   You security people are insane. I'm tired of this "only my version is correct" crap.

My favorite Linus quote of all time. I try to include it in every presentation I give.

> at https://lkml.kernel.org/r/alpine.LFD.0.999.0710010803280.3579@woody.linux-foundation.org .
>
> Many modules
>
>     SimpleFlow （ 2016/04/21 https://lwn.net/Articles/684825/ ）
>     HardChroot （ 2016/07/29 https://lwn.net/Articles/695984/ ）
>     Checmate （ 2016/08/04 https://lwn.net/Articles/696344/ ）
>     LandLock （ 2016/08/25 https://lwn.net/Articles/698226/ ）
>     PTAGS （ 2016/09/29 https://lwn.net/Articles/702639/ ）
>     CaitSith （ 2016/10/21 https://lwn.net/Articles/704262/ ）
>     SafeName （ 2016/05/03 https://lwn.net/Articles/686021/ ）
>     WhiteEgret （ 2017/05/30 https://lwn.net/Articles/724192/ ）
>     shebang （ 2017/06/09 https://lwn.net/Articles/725285/ ）
>     S.A.R.A. （ 2017/06/13 https://lwn.net/Articles/725230/ ）
>
> are proposed 5 or 6 years ago, but mostly became silent...

Yes. Unless a major distributor (Redhat, Canonical, ...) decides to
include it the upstream potential of an LSM is very limited.

> I still need byte-code analysis for finding the hook and code for making the hook
> writable in AKARI/CaitSith due to lack of EXPORT_SYMBOL_GPL(security_add_hooks).
> I wonder when I can stop questions like https://osdn.net/projects/tomoyo/lists/archive/users-en/2022-September/000740.html
> caused by https://patchwork.kernel.org/project/linux-security-module/patch/alpine.LRH.2.20.1702131631490.8914@namei.org/ .

The BPF people made noises about revamping the way LSM hooks get called
for performance reasons, but I have not seen a proposal from them. I have
assumed that they will get around to it eventually.

> Last 10 years, my involvement with Linux kernel is "fixing bugs" rather than
> "developing security mechanisms". Changes what I found in the past 10 years are:
>
>   As far as I'm aware, more than 99% of systems still disable SELinux. People use RHEL,
>   but the reason to choose RHEL is not because RHEL supports SELinux. The only thing
>   changed is that the way to disable SELinux changed from SELINUX=disabled in
>   /etc/selinux/config to selinux=0 on kernel command line options.

Re: LSM stacking in next for 6.1?

[Paul Moore]

On Thu, Sep 8, 2022 at 11:19 AM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> On 2022/08/03 9:01, Casey Schaufler 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.

> Many modules
>
>     SimpleFlow （ 2016/04/21 https://lwn.net/Articles/684825/ ）
>     HardChroot （ 2016/07/29 https://lwn.net/Articles/695984/ ）
>     Checmate （ 2016/08/04 https://lwn.net/Articles/696344/ ）
>     LandLock （ 2016/08/25 https://lwn.net/Articles/698226/ ）
>     PTAGS （ 2016/09/29 https://lwn.net/Articles/702639/ ）
>     CaitSith （ 2016/10/21 https://lwn.net/Articles/704262/ ）
>     SafeName （ 2016/05/03 https://lwn.net/Articles/686021/ ）
>     WhiteEgret （ 2017/05/30 https://lwn.net/Articles/724192/ ）
>     shebang （ 2017/06/09 https://lwn.net/Articles/725285/ ）
>     S.A.R.A. （ 2017/06/13 https://lwn.net/Articles/725230/ ）
>
> are proposed 5 or 6 years ago, but mostly became silent...

At least one of those, Landlock, has been merged upstream and is now
available in modern released Linux Kernels.  As far as the other LSMs
are concerned, I don't recall there ever being significant interest
among other developers or users to warrant their inclusion upstream.
If the authors believe that has changed, or is simply not true, they
are always welcome to post their patches again for discussion, review,
and potential upstreaming.  However, I will caution that it is
becoming increasingly difficult for people to find time to review
potential new LSMs so it may a while to attract sufficient comments
and feedback.

> I still need byte-code analysis for finding the hook and code for making the hook
> writable in AKARI/CaitSith due to lack of EXPORT_SYMBOL_GPL(security_add_hooks).
> I wonder when I can stop questions like https://osdn.net/projects/tomoyo/lists/archive/users-en/2022-September/000740.html
> caused by https://patchwork.kernel.org/project/linux-security-module/patch/alpine.LRH.2.20.1702131631490.8914@namei.org/ .

As has been discussed before, this isn't so much an issue with the
__ro_after_init change, it's really more of an issue of running
out-of-tree kernel code on pre-built distribution kernels, with
"pre-built" being the most important part.  It is my understanding
that if the user/developer built their own patched kernel this would
not likely be an issue as the out-of-tree LSM could be patched into
the kernel source.  The problem comes when the user/developer wants to
dynamically load their out-of-tree LSM into a pre-built distribution
kernel, presumably to preserve a level of distribution support.
Unfortunately, to the best of my knowledge, none of the major
enterprise Linux distributions will provide support for arbitrary
third-party kernel modules (it may work, but if something fails the
user is on their own to triage and resolve).

Beyond the support issue, there are likely to be other problems as
well since the kernel interfaces, including the LSM hooks themselves,
are not guaranteed to be stable across kernel releases.

> Last 10 years, my involvement with Linux kernel is "fixing bugs" rather than
> "developing security mechanisms". Changes what I found in the past 10 years are:
>
>   As far as I'm aware, more than 99% of systems still disable SELinux.

I would challenge you to support that claim with data.  Granted, we
are coming from very different LSM backgrounds, but I find that number
very suspect.  It has been several years since I last looked, but I
believe the latest published Android numbers would give some support
to the idea that more than 1% of SELinux based systems are running in
enforcing (or permissive) mode.  Significantly more.

>   People use RHEL,
>   but the reason to choose RHEL is not because RHEL supports SELinux.

Once again, if you are going to make strong claims such as this,
please provide data.  I know of several RHEL users that are only able
to run SELinux based systems as it is the only LSM which meets their
security requirements.

>   Instead, Ubuntu users are increasing, but the reason people choose Ubuntu is not because
>   Ubuntu supports AppArmor. Maybe because easy to use container environment. Maybe because
>   available as Windows Subsystem for Linux.

I suspect IBM/RH's decision to change CentOS' relationship to RHEL
also resulted in a number of users moving to Ubuntu, and that has
nothing to do with the LSMs.

>   However, in many cases, it seems that whether the OS is Windows or Linux no longer
>   matters. Programs are written using frameworks/languages which developers hardly care
>   about Windows API or Linux syscall. LSM significantly focuses on syscalls, but the
>   trend might no longer be trying to solve in the LSM layer...

Every LSM is different, that is partly why it is so interesting as a
security framework.  Look at Yama, look at AppArmor, look at Smack,
look at the BPF LSM ... there is no one security model, and claiming
that the LSM focuses on syscalls is misleading.  If you had to pick
only one concept that the LSM focuses on, I believe it would be
providing visibility and access controls for security relevant
interactions between entities on the system.  Processes opening files,
processes executing other processes, processes talking to each other
both across the network and on the local system.  Some of these things
involve syscalls, but as most of us know, making meaningful access
control decisions often involves much more than just the syscall.

> Also, Linux servers started using AntiVirus software. Enterprise AntiVirus software uses
> loadable kernel module that rewrites system call table rather than using LSM interface.
> It seems that people prefer out-of-the-box security over fine grained access control rule
> based security.

I would caution against confusing the security policy driven access
controls provided by many in-tree LSMs with out-of-tree antivirus
software.  They have different goals, different use cases, and
different user groups (markets).

I think that is about the nicest thing I can think to say about those
antivirus products ;)

--
paul-moore.com

Re: LSM stacking in next for 6.1?

[Tetsuo Handa]

On 2022/09/09 3:52, Paul Moore wrote:
> At least one of those, Landlock, has been merged upstream and is now
> available in modern released Linux Kernels.  As far as the other LSMs
> are concerned, I don't recall there ever being significant interest
> among other developers or users to warrant their inclusion upstream.
> If the authors believe that has changed, or is simply not true, they
> are always welcome to post their patches again for discussion, review,
> and potential upstreaming.  However, I will caution that it is
> becoming increasingly difficult for people to find time to review
> potential new LSMs so it may a while to attract sufficient comments
> and feedback.

Inclusion into upstream is far from the goal.

> As has been discussed before, this isn't so much an issue with the
> __ro_after_init change, it's really more of an issue of running
> out-of-tree kernel code on pre-built distribution kernels, with
> "pre-built" being the most important part.  It is my understanding
> that if the user/developer built their own patched kernel this would
> not likely be an issue as the out-of-tree LSM could be patched into
> the kernel source.

There always is LSM module which is not enabled in pre-built distribution kernels.
https://bugzilla.redhat.com/show_bug.cgi?id=542986

Even if source code is already available in distribution kernels, as long as
distribution refuses to include into pre-built distribution kernels, it is no
different from the out-of-tree LSM.

The user/developer has to rebuild the whole distribution kernels is an unacceptable
barrier.

>                     The problem comes when the user/developer wants to
> dynamically load their out-of-tree LSM into a pre-built distribution
> kernel, presumably to preserve a level of distribution support.

Not only for preserving the level of distribution support. But also for
allowing immediate updates whenever distribution kernels are updated, and
allowing out of kernel modules (e.g. from AntiVirus, hardware vendors) to be
loaded into pre-built distribution kernels (instead of user/developer rebuilt
distribution kernels).

> Unfortunately, to the best of my knowledge, none of the major
> enterprise Linux distributions will provide support for arbitrary
> third-party kernel modules (it may work, but if something fails the
> user is on their own to triage and resolve).

I know it, especially Red Hat is strict regarding that. Red Hat does not provide
support for rebuilt kernels even with zero changes (e.g. same kernel source code,
same kernel configuration).

Some hardware vendors provide support for their device drivers when used with
RHEL kernel but does not provide support when used with CentOS kernel (not
CentOS Stream), despite there is effectively no difference. Being able to
continue using pre-built distribution kernels is a fatal requirement for users.

> 
> Beyond the support issue, there are likely to be other problems as
> well since the kernel interfaces, including the LSM hooks themselves,
> are not guaranteed to be stable across kernel releases.

That's not a big problem. Loadable LSM modules will be updated as the kernel
interfaces change.

But the combination of "the kernel interfaces does not legally allow loadable LSM modules"
and "distributors do not enable LSMs already available in upstream kernels" and "it is
becoming increasingly difficult for people to find time to review potential new LSMs" and
"it is difficult for users/developers to continue rebuilding distributor kernels only for
enabling LSMs" indicates there is no space for LSMs which are not enabled in pre-built
distribution kernels to survive; it is tantamount to a death sentence.
Legally allowing loadable LSM modules is an answer to current situation.



> 
>> Last 10 years, my involvement with Linux kernel is "fixing bugs" rather than
>> "developing security mechanisms". Changes what I found in the past 10 years are:
>>
>>   As far as I'm aware, more than 99% of systems still disable SELinux.
> 
> I would challenge you to support that claim with data.

Unfortunately, that's an impossible request for me. I worked at a support center
for three years, and I found (from e.g. sosreport) that no system enabled SELinux.
Since I already left the support center, I'm no longer in a position who can
collect statistic data.

>                                                         Granted, we
> are coming from very different LSM backgrounds, but I find that number
> very suspect.  It has been several years since I last looked, but I
> believe the latest published Android numbers would give some support
> to the idea that more than 1% of SELinux based systems are running in
> enforcing (or permissive) mode.  Significantly more.

In know-how manuals developed by the support center, disabling SELinux is the
first action after installation, and people using the support center follow it.
(I personally feel that using SELinux with targeted policy is possible. But
they hate troubles caused by unwanted functionality. And they can't afford
keeping SELinux enabled because nobody can adjust policy for their servers.
If troubles caused by SELinux happen, even I won't be able to provide support
because I'm not in a position to understand and manage the details/usage of
their servers.)

You might wonder how they are protecting their servers without SELinux.
It is a mystery.

But I if recall the days at the support center, I seldom saw servers which
directly face the Internet. Maybe they are using security appliance for servers
facing the Internet, and using RHEL for servers in already secured environment.

Then, the need to enable SELinux remains still low sounds realistic.
For example, telnet and ftp are used even nowadays in some systems.
https://bugzilla.redhat.com/show_bug.cgi?id=1853102
https://bugzilla.redhat.com/show_bug.cgi?id=1914536

But again, I'm not in a position for collecting statistic data.

> 
>>   People use RHEL,
>>   but the reason to choose RHEL is not because RHEL supports SELinux.
> 
> Once again, if you are going to make strong claims such as this,
> please provide data.  I know of several RHEL users that are only able
> to run SELinux based systems as it is the only LSM which meets their
> security requirements.

Sure, there are systems where SELinux is the only choice.
But surely there are systems where SELinux is not the only choice.

> I would caution against confusing the security policy driven access
> controls provided by many in-tree LSMs with out-of-tree antivirus
> software.  They have different goals, different use cases, and
> different user groups (markets).

But due to the above-mentioned death sentence, we currently can't allow
users/developers to use different LSMs which have different goals,
different use cases, and different user groups (markets). Very bad...

Re: LSM stacking in next for 6.1?

[Paul Moore]

On Fri, Sep 9, 2022 at 7:33 AM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> On 2022/09/09 3:52, Paul Moore wrote:
> > At least one of those, Landlock, has been merged upstream and is now
> > available in modern released Linux Kernels.  As far as the other LSMs
> > are concerned, I don't recall there ever being significant interest
> > among other developers or users to warrant their inclusion upstream.
> > If the authors believe that has changed, or is simply not true, they
> > are always welcome to post their patches again for discussion, review,
> > and potential upstreaming.  However, I will caution that it is
> > becoming increasingly difficult for people to find time to review
> > potential new LSMs so it may a while to attract sufficient comments
> > and feedback.
>
> Inclusion into upstream is far from the goal.

For better or worse, there is a long history of the upstream Linux
Kernel focusing only on in-tree kernel code, I see no reason why we
should change that now for LSMs.  I am sorry that this approach
negatively affects the LSMs you mentioned, but if they are not
interested in being merged upstream there is not much we can do to
help.

-- 
paul-moore.com

Re: LSM stacking in next for 6.1?

[Tetsuo Handa]

On 2022/09/14 22:56, Paul Moore wrote:
> On Fri, Sep 9, 2022 at 7:33 AM Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:
>> Inclusion into upstream is far from the goal.
> 
> For better or worse, there is a long history of the upstream Linux
> Kernel focusing only on in-tree kernel code, I see no reason why we
> should change that now for LSMs.

Because we can't afford accepting/maintaining whatever LSMs that are proposed.

Do you think that we are going to accept/maintain whatever LSMs that are proposed
if we get to the point to "The commitment I made to Paul some years ago now was
that the stacking would eventually include making all combinations possible" ?
I don't think so.

Although the upstream Linux Kernel focuses only on in-tree kernel code,
CONFIG_MODULES=y is not limited for in-tree kernel code. It is used by e.g.
device vendors to deliver their out-of-tree driver code. Then, I see no reason
why we can't do the same for LSMs. We simply don't need to "provide efforts for
fixing bugs in whatever LSMs"; we simply should "allow whatever LSMs to exist".

Re: LSM stacking in next for 6.1?

[Casey Schaufler]

On 9/15/2022 7:27 AM, Tetsuo Handa wrote:
> On 2022/09/14 22:56, Paul Moore wrote:
>> On Fri, Sep 9, 2022 at 7:33 AM Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:
>>> Inclusion into upstream is far from the goal.
>> For better or worse, there is a long history of the upstream Linux
>> Kernel focusing only on in-tree kernel code, I see no reason why we
>> should change that now for LSMs.
> Because we can't afford accepting/maintaining whatever LSMs that are proposed.

We've done a reasonable job so far. Part of the process of getting a security
module upstream is demonstrating that it will (1) add value, (2) get used and
(3) continue to be maintained.  Several modules have been proposed that looked
like they would add value and get used, but that the author(s) had no means to
maintain.

> Do you think that we are going to accept/maintain whatever LSMs that are proposed
> if we get to the point to "The commitment I made to Paul some years ago now was
> that the stacking would eventually include making all combinations possible" ?
> I don't think so.

Neither do I. What I want to do is break down the existing technical barrier.
If Redhat wants to continue with their "SELinux only" position, that's their
call. If Ubuntu wants to take a more inclusive approach they should be able
to. That does not mean that every bizarre and/or unnatural security module
that's proposed should be included in the mainline.

> Although the upstream Linux Kernel focuses only on in-tree kernel code,
> CONFIG_MODULES=y is not limited for in-tree kernel code. It is used by e.g.
> device vendors to deliver their out-of-tree driver code.

I see this argument all the time. The response is "get your driver upstream".
Vendors/developers who whine "It's too hard" get no sympathy from me.

>  Then, I see no reason
> why we can't do the same for LSMs. We simply don't need to "provide efforts for
> fixing bugs in whatever LSMs"; we simply should "allow whatever LSMs to exist".
>

Re: LSM stacking in next for 6.1?

[Tetsuo Handa]

On 2022/09/16 0:50, Casey Schaufler wrote:
>> Although the upstream Linux Kernel focuses only on in-tree kernel code,
>> CONFIG_MODULES=y is not limited for in-tree kernel code. It is used by e.g.
>> device vendors to deliver their out-of-tree driver code.
> 
> I see this argument all the time. The response is "get your driver upstream".
> Vendors/developers who whine "It's too hard" get no sympathy from me.
> 

Getting off-topic from loadable module LSMs, but one of reasons they do not
try to get upstream might be to be able to synchronize across multiple kernel
versions. For example, splx_kernel_module-3.0.1.0024-src.tar.gz is trying to
serve as a common source code for many distributor's kernel versions.

If some snapshot were included in upstream kernel, it becomes difficult to keep
the same bugfixes/features applied across kernel versions the vendor wants to
load into.

Although ./scripts/checkpatch.pl warns about use of LINUX_VERSION_CODE, there are
cases where vendors want to share the same bugfixes/features across all kernel
versions.