LSM stacking in next for 6.1?

[Paul Moore]

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