On Mon, Jul 22, 2019 at 6:01 PM Casey Schaufler <ca...@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. -- paul moore www.paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
