11:41 a.m.
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.
>>>> 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>.
Fair point.
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.
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.
>>> 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.
Why? A combined-label API is what the application developers asked for.
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.
??????? This is exactly what I've provided.
"apparmor\0unconfined\0smack\0User\0"
You know exactly what LSMs are providing data and what that data is.
How could it be clearer or cleaner?
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;
Are you saying that interface_lsm changes the /proc/.../attr/current API?
That API is already dependent on the active security module. You may get
an AppArmor, SELinux or Smack context from that API. It's been thus for a
long time. Creating the smack and apparmor subdirectories was done to help
make this cleaner. But those are new APIs. The existing applications either
allow for a variety of security modules (e.g. ps(1)) or need to check for
a particular one (e.g. id(1), which doesn't need to and would be better if
it didn't, but what the hay). If they don't they are flawed and should be
repaired.
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.
Agreed. That's why the proposed APIs have been discussed with many
of those application communities.
>>>> 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.
That's what I've been proposing all along. You don't like the APIs.
What don't you like about them? I believe they address the objections
you've raised. I know that I can be real obtuse from time to time,
but I don't see how they fail to meet your requirements.