2:32 p.m.
On Thu, Sep 8, 2022 at 2:05 PM Casey Schaufler <casey(a)schaufler-ca.com> wrote:
On 9/7/2022 8:57 PM, Paul Moore wrote:
> On Wed, Sep 7, 2022 at 7:53 PM Casey Schaufler <casey(a)schaufler-ca.com>
wrote:
>> On 9/7/2022 4:27 PM, Paul Moore wrote:
...
>>> 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).
>> There was a lot of discussion regarding that. My proposed
>> apparmor="unconfined",smack="User" format was panned for
those same reasons.
>> The nil byte format has been used elsewhere and suggested for that reason.
> Based on what I recall from those discussions, it was my impression
> the nil byte label delimiter was suggested simply because no one was
> entertaining the idea of using something other than the existing
> procfs interface. It is my opinion that we've taken that interface
> about as far as it can go, and while it needs to stay intact for
> compatibility reasons, the LSM stacking functionality should move to a
> different API that is better suited for it.
It's going to raise its ugly head again with SO_PEERCONTEXT for the
SELinux+Smack case. But we can cross that bridge when we come to it.
There are also problems with IP_PASSSEC/SCM_SECURITY that we've never
fully resolved (and have gotten a bit lucky over the years); it very
well could be time to add support for IP_SECURITY as the multi-LSM
replacement for SCM_SECURITY. We could leverage the same LSM context
structures as in the other multi-LSM interfaces. Existing
applications could continue to use SCM_SECURITY; in fact I believe we
could have both SCM_SECURITY and IP_SECURITY in the same message for
maximum compatibility.
https://github.com/SELinuxProject/selinux-kernel/issues/24
For SO_PEERSEC, we should probably just introduce SO_PEERSEC2 or
similar, using the same multi-LSM context structures as the other
interfaces.
> In case it helps spur your imagination, here is a revised
strawman:
>
> /**
> * struct lsm_ctx - LSM context
> * @id: the LSM id number, see LSM_ID_XXX
A LSM ID hard coded in a kernel header makes it harder to develop new
security modules.
There is so much precedence for defining a token scalar value to
represent a "thing" that I don't know where to begin. Look at IANA,
there are entire organizations that exist to map "things" to numbers.
If you're objecting to assigning LSMs fixed integer numbers you've got
to give me some very explicit reasons (complete with examples) as to
why that would be a mistake.
The security module can't be self contained. I say
that, but I acknowledge that I've done the same kind of thing with the
definition of the struct lsmblob. That isn't part of an external API
however.
I'm not following you here. See my comment above about better examples.
It may also interfere with Tetsuo's long standing request that
we don't do things that prevent the possibility of loadable security
modules at some point in the future.
I already replied to Tetsuo's email, and while this particular point
about LSM ID numbers wasn't directly addressed, my response there
seems to apply equally well here: it's not so much about loadable
LSMs, it's about out-of-tree LSMs. These are two very different
things, with different solutions.
On the other hand, there's no great way to include two variable
length
strings in a structure like this. So unless we adopt something as ugly
as the nil byte scheme this is supposed to replace I expect we're stuck
with an LSM ID.
I don't like making general comments, but when in doubt, consider me
not-a-fan of string-based identifiers in APIs. Give me token scalar
values instead.
> * @flags: LSM specific flags, zero if unused
For an API shouldn't this be a specific size? u32? I'm not really
up to date on the guidance regarding which it should be.
Enh, sure, whatever. You'll remember my initial comment about not
being a syscall stylist; if the discussion has moved to seriously
discussing the syscall prototypes we should likely start a new thread
and bring in the syscall folks ... I vaguely remember there was a
mailing list for syscalls and API changes ...
I will head in this direction. A couple questions:
Would we want lsm_prev_ctx() as well as lsm_current_ctx(),
I'm not sure I'm following your thinking, what would lsm_prev_ctx() do?
or should we use the lsm_ctx->flags to identify the provided
context? If we did that we should have an lsm_ctx() system call
that returns the current, prev, and whatever other security
module specific attributes might be associated with the process,
each identified in the flags field. While the "current" context
is usually what we're after, there may be cases where the other
attributes are desired.
I don't understand what you mean by "prev"{ious} attributes. I'm
thinking of lsm_current_ctx() as a multi-LSM replacement for
/proc/self/attr/current. If, for example, we wanted something for
/proc/self/attr/exec I imagine we would create lsm_current_exec(), or
something similarly named, with a similar prototype.
Or perhaps we try to stick a bit closer to the procfs naming and go
with lsm_self_cur(...) and lsm_self_exec(...). All things to discuss.
--
paul-moore.com