linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: "linux-audit@redhat.com" <linux-audit@redhat.com>,
	Linux Security Module list 
	<linux-security-module@vger.kernel.org>,
	Paul Moore <paul@paul-moore.com>,
	rgb@redhat.com
Subject: Re: Preferred subj= with multiple LSMs
Date: Sat, 13 Jul 2019 11:08:41 -0400	[thread overview]
Message-ID: <2268017.8MBUnBNn7u@x2> (raw)
In-Reply-To: <f824828c-5c9d-b91e-5cec-70ee7a45e760@schaufler-ca.com>

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.

-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.





  reply	other threads:[~2019-07-13 15:08 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-12 16:33 Preferred subj= with multiple LSMs Casey Schaufler
     [not found] ` <c46932ec-e38e-ba15-7ceb-70e0fe0ef5dc@schaufler-ca.com>
2019-07-13 15:08 ` Steve Grubb [this message]
2019-07-15 19:04   ` Richard Guy Briggs
     [not found] ` <1979804.kRvuSoDnao@x2>
     [not found]   ` <2802ddee-b621-c2eb-9ff3-ea15c4f19d0c@schaufler-ca.com>
     [not found]     ` <3577098.oGDFHdoSSQ@x2>
2019-07-16 17:16       ` Casey Schaufler
     [not found]   ` <CAHC9VhSELVZN8feH56zsANqoHu16mPMD04Ww60W=r6tWs+8WnQ@mail.gmail.com>
2019-07-16 17:29     ` Casey Schaufler
2019-07-16 17:43       ` Paul Moore
2019-07-16 17:58         ` Casey Schaufler
2019-07-16 18:06         ` Steve Grubb
2019-07-16 18:41           ` Casey Schaufler
2019-07-16 21:25             ` Paul Moore
2019-07-16 21:46               ` Steve Grubb
2019-07-16 22:18                 ` Casey Schaufler
2019-07-16 23:13                   ` Paul Moore
2019-07-16 23:47                     ` Casey Schaufler
2019-07-17 12:14                       ` Paul Moore
2019-07-17 15:49                         ` Casey Schaufler
2019-07-17 16:23                           ` Paul Moore
2019-07-17 23:02                             ` Casey Schaufler
2019-07-18 13:10                               ` Simon McVittie
2019-07-18 16:13                                 ` Casey Schaufler
2019-07-19 12:15                                   ` Simon McVittie
2019-07-19 16:29                                     ` Casey Schaufler
2019-07-19 18:47                                       ` Simon McVittie
2019-07-19 20:02                                         ` Dbus and multiple LSMs (was Preferred subj= with multiple LSMs) Casey Schaufler
2019-07-22 11:36                                           ` Simon McVittie
2019-07-22 16:04                                             ` Casey Schaufler
2019-07-19 21:21                               ` Preferred subj= with multiple LSMs Paul Moore
2019-07-22 20:50                                 ` James Morris
2019-07-22 22:01                                   ` Casey Schaufler
2019-07-22 22:30                                     ` Paul Moore
2019-07-23  0:11                                       ` Casey Schaufler
2019-07-23 14:06                                       ` Simon McVittie
2019-07-23 17:32                                         ` Casey Schaufler
2019-07-23 21:46                                         ` James Morris
2019-07-16 23:09                 ` Paul Moore
2019-07-17  4:36                   ` James Morris
2019-07-17 12:23                     ` Paul Moore
2019-07-18 15:01               ` William Roberts
2019-07-18 18:48                 ` Casey Schaufler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2268017.8MBUnBNn7u@x2 \
    --to=sgrubb@redhat.com \
    --cc=casey@schaufler-ca.com \
    --cc=linux-audit@redhat.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=rgb@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).