Preferred subj= with multiple LSMs

[Paul Moore]

On Mon, Jul 15, 2019 at 6:56 PM Steve Grubb <sgrubb at redhat.com> 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 <casey at schaufler-ca.com>
> wrote:
> > > On 7/15/2019 12:04 PM, Richard Guy Briggs wrote:
> > > > On 2019-07-13 11:08, Steve Grubb wrote:

...

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

I suppose it is all somewhat "subjective" - bad joke fully intended :)
- with respect to what one considers good/bad/limiting.  My personal
view is that an ideal solution would allow for multiple independent
subj/obj labels without having to multiplex on a single subj/obj
field.  My gut feeling is that this would confuse your tools, yes?

> 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

Some quick comments:

* My usual reminder that new fields for existing audit records must be
added to the end of the record.

* If we are going to multiplex the labels on a single field (more on
that below) I might suggest using "subj_lsms" instead of "lsms" so we
leave ourself some wiggle room in the future.

* Multiplexing on a single "subj" field is going to be difficult
because picking the label delimiter is going to be a pain.  For
example, in the example above a comma is used, which at the very least
is a valid part of a SELinux label and I suspect for Smack as well
(I'm not sure about the other LSMs).  I suspect the only way to parse
out the component labels would be to have knowledge of the LSMs in
use, as well as the policies loaded at the time the audit record was
generated.

This may be a faulty assumption, but assuming your tools will fall
over if they see multiple "subj" fields, could we do something like
the following (something between option #2 and #3):

  subj1_lsm=smack subj1=<smack_label> subj2_lsm=selinux
subj2=<selinux_label> ...

-- 
paul moore
www.paul-moore.com