Re: LSM stacking in next for 6.1?
On Wed, Sep 7, 2022 at 12:42 PM Casey Schaufler <casey(a)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(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 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