From mboxrd@z Thu Jan 1 00:00:00 1970 From: Casey Schaufler Subject: Re: Preferred subj= with multiple LSMs Date: Tue, 16 Jul 2019 09:00:05 -0700 Message-ID: <2802ddee-b621-c2eb-9ff3-ea15c4f19d0c@schaufler-ca.com> References: <1979804.kRvuSoDnao@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx15.extmail.prod.ext.phx2.redhat.com [10.5.110.44]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7B7DB5E7A9 for ; Tue, 16 Jul 2019 16:00:10 +0000 (UTC) Received: from sonic310-22.consmr.mail.bf2.yahoo.com (sonic310-22.consmr.mail.bf2.yahoo.com [74.6.135.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CFC6E30832C3 for ; Tue, 16 Jul 2019 16:00:08 +0000 (UTC) In-Reply-To: <1979804.kRvuSoDnao@x2> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb , Paul Moore Cc: Richard Guy Briggs , "linux-audit@redhat.com" List-Id: linux-audit@redhat.com On 7/15/2019 3:55 PM, Steve Grubb wrote: > On Monday, July 15, 2019 5:28:56 PM EDT Paul Moore wrote: >> On Mon, Jul 15, 2019 at 3:37 PM Casey Schaufler > wrote: >>> On 7/15/2019 12:04 PM, Richard Guy Briggs wrote: >>>> 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. >>> I too, am uncomfortable regarding record parsing. > The record parsing for this is good as long as we are smart about it. We have > to be able to do searches on subject and object labels. By default, ausearch > uses strstr() to find a fragment of a label. That would still work the same > with multiple labels if done right. > > >> If you can find me someone who is happy and comfortable with the >> current state of the audit record and/or formatting I would love to >> see them :) >> >>>> 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. >>> It doesn't address the issue of success records, or records >>> generated outside the security modules. >> Yes, exactly. The individual LSM will presumably will continue to >> generate their own audit records as they do today and I would imagine >> that the subject and object fields could remain as they do today for >> the LSM specific records. >> >> The trick is the other records which are not LSM specific but still >> want to include subject and/or object information. Unfortunately we >> are stuck with some tough limitations given the current audit record >> format and Steve's audit userspace tools; > Not really. We just need to approach the problem thinking about how to make > it work based on how things currently work. For example Casey had a list of > possible formats. Like this one: > > Option 3: > lsms=selinux,apparmor subj=x:y:z:s:c subj=a > > I'd suggest something almost like that. The first field could be a map to > decipher the labels. Then we could have a comma separated list of labels. > > lsms=selinux,apparmor subj=x:y:z:s:c,a Unless there's an objection I will use this format with a slight modification. Smack allows commas in labels, so using a bare comma can lead to ambiguity. lsms=smack,apparmor subj="TS/Alpha,Beta","a" It's more code change than some of the other options, but if it has the best chance of working with user space I'm game. Thank you. > > Since ausearch uses strstr(), this will still work. > >> I can toss out some suggestions but it would be nice to hear what Steve's >> tools would support with respect to LSM subject/object value formats. >> Steve, are these values interpreted at all by your tools, or are the opaque >> values? > subject label attributes are treat as strings. There is no attempt to > interpret portions of the strings to have any meaning. The main requirement > is that they have to be searchable. > > -Steve > >