SELinux Archive on
 help / color / Atom feed
From: Paul Moore <>
To: Aaron Goidel <>
Cc: Stephen Smalley <>,
	Richard Guy Briggs <>,,,, James Morris <>,,,, Nicholas Franck <>,
	Serge Hallyn <>
Subject: Re: [Non-DoD Source] Re: [RFC PATCH v2] security, capability: pass object information to security_capable
Date: Fri, 16 Aug 2019 12:29:08 -0400
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Aug 15, 2019 at 9:11 AM Aaron Goidel <> wrote:
> I'm looking at how to enable LSMs to selectively turn on audit
> collection. So there seems to be two key points: audit_alloc() and
> __audit_syscall_entry(). Would it suffice to define a single boolean
> hook that takes the task and call it from both functions, to decide
> whether to override an AUDIT_DISABLED state in audit_alloc() and to
> override a 0 audit_n_rules in __audit_syscall_entry(). In audit_alloc()
> if audit_filter_task() returned AUDIT_DISABLED and the hook returned
> true, we would change the state to AUDIT_BUILD_CONTEXT. In
> __audit_syscall_entry(), if the hook returned true, we would set dummy
> to 0. Obviously, we could have a more general hook which lets us return
> arbitrary audit states, but, it isn't clear how we would reconcile
> conflicting results from audit_filter_task() and the hook for any
> situation other than AUDIT_DISABLED. We could also potentially use a
> different hook in __audit_syscall_entry(), though I don't think that we
> want the LSMs trying to interpret the syscall number or arguments.
> Do you think that is sufficiently general or would you suggest something
> different?

FWIW, I think treating the per-task audit switch as a boolean is fine;
I don't think we want other in-kernel callers to have to worry about
the different audit states.  From their perspective it is either "on"
or "off".

However, I think there are two parts of the greater LSM-enables-audit
discussion, and we're only discussing the first part: collection.  The
second part is the actual audit record generation, and I think this
part is going to be less clear.  While the changes to audit_alloc(),
etc. are necessary to be able to do any meaningful audit later on, I'm
thinking introducing some granularity and LSM control to what gets
generated in audit_log_exit() might be very welcome both from a
performance and log cleanliness perspective.

Some random thoughts on this (some may be way off, but I want to start
with some expectations):
* The LSM should never be able to block collection/generation of audit
records, just enable additional records.
* The LSM controls should only affect what we call the "syscall
auditing" bits, e.g. the stuff in auditsc.c.  Audit records that
happen outside of this should be untouched, the AVC records are an
example of a record that exists independent of syscall auditing.
* We should be able to have the LSM set a per-syscall audit enable
flag which would be checked in audit_log_exit() (or
* It's not clear to me if we want to provide some granularity to the
LSM regarding what records get generated in audit_log_exit(), for
example do we allow the LSM to request just PATH records?  I'm
guessing we wouldn't want to specify record types directly, but
perhaps record "classes", e.g. "file".

I'm not sure if any of this is going to be a good idea, but I think we
need to discuss it a bit before we start duplicating things in

paul moore

      reply index

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-01 14:43 [RFC PATCH v2] security,capability: " Aaron Goidel
2019-08-08 16:30 ` Paul Moore
2019-08-13 15:01   ` [Non-DoD Source] Re: [RFC PATCH v2] security, capability: " Aaron Goidel
2019-08-13 21:27     ` Richard Guy Briggs
2019-08-14 19:59       ` Paul Moore
2019-08-14 21:08         ` Stephen Smalley
2019-08-14 21:27           ` Paul Moore
2019-08-15 13:10             ` [Non-DoD Source] " Aaron Goidel
2019-08-16 16:29               ` Paul Moore [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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

SELinux Archive on

Archives are clonable:
	git clone --mirror selinux/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 selinux selinux/ \
	public-inbox-index selinux

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone