From: Steve Grubb <sgrubb@redhat.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: LSM <linux-security-module@vger.kernel.org>,
Linux Audit <linux-audit@redhat.com>
Subject: Re: Differentiating audit rules in an LSM stack
Date: Tue, 02 Jan 2018 10:35:04 -0500 [thread overview]
Message-ID: <1847115.7IfdG6fre4@x2> (raw)
In-Reply-To: <a1f773ca-924d-1428-c8b3-0bf77f6cf796@schaufler-ca.com>
[-- Attachment #1.1: Type: text/plain, Size: 1397 bytes --]
On Friday, December 22, 2017 3:01:24 PM EST Casey Schaufler wrote:
> The audit rule field types AUDIT_SUBJ_* and AUDIT_OBJ_* are
> defined generically and used by both SELinux and Smack to identify
> fields that are interesting to them. If SELinux and Smack are running
> concurrently both modules will identify audit rules as theirs if
> either has requested the field. Before I go off and create a clever
> solution I think it wise to ask if anyone has thought about or has
> strong opinions on how best to address this unfortunate situation.
>
> We know that SELinux and Smack together is not an especially
> interesting configuration. It is, however, a grand test case for
> generality of the solution. Any module that wanted to audit fields
> that are defined generically will have this sort of problem.
I'd suggest adding a "lsm=x" field at the beginning so that anyone parsing it can
parse appropriately as it encounters the following fields. This really needs to be
known early in the parsing rather than at the end.
But another thing to consider is that auditctl can load rules that match any part of
the subject/object label as whole words. Meaning I can write a rule to match the
selinux type, role, user or level part of the label. That would then make me
wonder if we need to tell the rule engine which lsm provides the representation
so that a proper match is done?
-Steve
[-- Attachment #1.2: Type: text/html, Size: 4480 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
prev parent reply other threads:[~2018-01-02 15:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-22 20:01 Differentiating audit rules in an LSM stack Casey Schaufler
2017-12-22 21:02 ` Paul Moore
2018-01-02 15:48 ` Steve Grubb
2018-01-02 17:05 ` Casey Schaufler
2018-01-02 17:20 ` Casey Schaufler
2018-01-02 15:35 ` Steve Grubb [this message]
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=1847115.7IfdG6fre4@x2 \
--to=sgrubb@redhat.com \
--cc=casey@schaufler-ca.com \
--cc=linux-audit@redhat.com \
--cc=linux-security-module@vger.kernel.org \
/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).