Re: Preferred subj= with multiple LSMs

From: Richard Guy Briggs <rgb@redhat.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: Casey Schaufler <casey@schaufler-ca.com>,
	"linux-audit@redhat.com" <linux-audit@redhat.com>,
	Linux Security Module list 
	<linux-security-module@vger.kernel.org>,
	Paul Moore <paul@paul-moore.com>
Subject: Re: Preferred subj= with multiple LSMs
Date: Mon, 15 Jul 2019 15:04:57 -0400	[thread overview]
Message-ID: <20190715190457.pqlaxjcxhdcosdsz@madcap2.tricolour.ca> (raw)
In-Reply-To: <2268017.8MBUnBNn7u@x2>

On 2019-07-13 11:08, Steve Grubb wrote:
> Hello,
> 
> On Friday, July 12, 2019 12:33:55 PM EDT Casey Schaufler wrote:
> > Which of these options would be preferred for audit records
> > when there are multiple active security modules?
> 
> I'd like to start out with what is the underlying problem that results in 
> this? For example, we have pam. It has multiple modules each having a vote. 
> If a module votes no, then we need to know who voted no and maybe why. We 
> normally do not need to know who voted yes.
> 
> So, in a stacked situation, shouldn't each module make its own event, if 
> required, just like pam? And then log the attributes as it knows them? Also, 
> what model is being used? Does first module voting no end access voting? Or 
> does each module get a vote even if one has already said no?
> 
> Also, we try to keep LSM subsystems separated by record type numbers. So, 
> apparmour and selinux events are entirely different record numbers and 
> formats. Combining everything into one record is going to be problematic for 
> reporting.

I was wrestling with the options below and was uncomfortable with all of
them because none of them was guaranteed not to break existing parsers.

Steve's answer is the obvious one, ideally allocating a seperate range
to each LSM with each message type having its own well defined format.

> -Steve
> 
> > I'm not asking
> > if we should do it, I'm asking which of these options I should
> > implement when I do do it. I've prototyped #1 and #2. #4 is a
> > minor variant of #1 that is either better for compatibility or
> > worse, depending on how you want to look at it. I understand
> > that each of these offer challenges. If I've missed something
> > obvious, I'd be delighted to consider #5.
> > 
> > Thank you.
> > 
> > Option 1:
> > 
> > 	subj=selinux='x:y:z:s:c',apparmor='a'
> > 
> > Option 2:
> > 
> > 	subj=x:y:z:s:c subj=a
> > 
> > Option 3:
> > 
> > 	lsms=selinux,apparmor subj=x:y:z:s:c subj=a
> > 
> > Option 4:
> > 
> > 	subjs=selinux='x:y:z:s:c',apparmor='a'
> > 
> > Option 5:
> > 
> > 	Something else.

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635