Re: Preferred subj= with multiple LSMs
On 7/22/2019 3:30 PM, Paul Moore wrote:
On Mon, Jul 22, 2019 at 6:01 PM Casey Schaufler
<casey(a)schaufler-ca.com> wrote:
> On 7/22/2019 1:50 PM, James Morris wrote:
>> On Fri, 19 Jul 2019, Paul Moore wrote:
>>
>>>> We've never had to think about having general rules on
>>>> what security modules do before, because with only one
>>>> active each could do whatever it wanted without fear of
>>>> conflict. If there is already a character that none of
>>>> the existing modules use, how would it be wrong to
>>>> reserve it?
>>> "We've never had to think about having general rules on what
security
>>> modules do before..."
>>>
>>> We famously haven't imposed restrictions on the label format before
>>> now, and this seems like a pretty poor reason to start.
>> Agreed.
> In a follow on thread
>
> https://www.spinics.net/lists/linux-security-module/msg29996.html
>
> we've been discussing the needs of dbus-daemon in a multiple LSM
> environment. I suggest that if supporting dbus well is assisted by
> making reasonable restrictions on what constitutes a valid LSM
> "context" that we have a good reason. While there are ways to
> present groups of arbitrary hunks of data, why would we want to?
I continue to believe that restrictions on the label format are a bad
idea, and I further believe that multiplexing the labels is going to
be a major problem that will haunt us for many, many years. If we are
going to support multiple simultaneous LSMs I think we need to find a
way to represent those labels independently.
Let's review the bidding:
Audit wants to maintain backward compatibility while also getting
the information about multiple subject and object labels. The current
proposal:
... subj=a:b:c:d \
... obj=e:f:g:h obj_selinux=e:f:g:h obj_mumble=Crivens \
... subj_selinux=a:b:c:d subj_mumble=Feegle \
...
where obj_<lsm> and subj_<lsm> are only provided if there's more than
one active "display" LSM.
Dbus wants an atomic fetch of the security attributes from a socket
and from a /proc entry. We don't want to break compatibility, so new
interfaces are provided:
SO_PEERCONTEXT - packet label in the "Hideous" format
/proc/.../attr/context - process label in the "Hideous" format
Legacy programs want the security attributes from a socket
and from a /proc entry. Since they don't know how to differentiate
which security module is active, these are controlled by the
"display", which defaults to the first module loaded that provides
a secid_to_secctx() hook. (not quite the definition, but close enough)
SO_PEERSEC - "display" LSM packet label in module native format
/proc/.../attr/display - set/get the "display" value
/proc/.../attr/current - "display" LSM process label in module native format
/proc/.../attr/smack/current - Smack process label in module native format
A classic Android, Tizen, Fedora or Ubuntu system will continue to use these
interfaces and see no difference in behavior.
A system that really wants to use multiple "display"ing modules will
have the same issues that dbus has, and will likely convert to the new,
"hideous" interfaces, especially if a liblsm (NOT libsecurity!) is
provided.