Re: LSM stacking in next for 6.1?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Sep 7, 2022 at 1:23 PM John Johansen
<john.johansen@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> wrote:
> >>> On 9/6/22 16:24, Paul Moore wrote:
> >>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
> >>>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
> >>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> >>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> 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



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux