LSM stacking in next for 6.1?

[Paul Moore]

On Tue, Sep 6, 2022 at 8:31 PM Casey Schaufler <casey at 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 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:
> >>>>> 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