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