Preferred subj= with multiple LSMs

[Casey Schaufler]

On 7/22/2019 3:30 PM, Paul Moore wrote:
> On Mon, Jul 22, 2019 at 6:01 PM Casey Schaufler <casey at 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.