linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Guy Briggs <rgb@redhat.com>
To: "Michael Weiß" <michael.weiss@aisec.fraunhofer.de>
Cc: Paul Moore <paul@paul-moore.com>,
	Casey Schaufler <casey@schaufler-ca.com>,
	Mike Snitzer <snitzer@redhat.com>,
	linux-kernel@vger.kernel.org, Eric Paris <eparis@redhat.com>,
	linux-raid@vger.kernel.org, Song Liu <song@kernel.org>,
	dm-devel@redhat.com, linux-audit@redhat.com,
	Alasdair Kergon <agk@redhat.com>
Subject: Re: [PATCH v4 0/3] dm: audit event logging
Date: Tue, 7 Sep 2021 20:59:42 -0400	[thread overview]
Message-ID: <20210908005942.GJ490529@madcap2.tricolour.ca> (raw)
In-Reply-To: <20210904095934.5033-1-michael.weiss@aisec.fraunhofer.de>

On 2021-09-04 11:59, Michael Weiß wrote:
> dm integrity and also stacked dm crypt devices track integrity
> violations internally. Thus, integrity violations could be polled
> from user space, e.g., by 'integritysetup status'.
> 
> >From an auditing perspective, we only could see that there were
> a number of integrity violations, but not when and where the
> violation exactly was taking place. The current error log to
> the kernel ring buffer, contains those information, time stamp and
> sector on device. However, for auditing the audit subsystem provides
> a separate logging mechanism which meets certain criteria for secure
> audit logging.
> 
> With this small series we make use of the kernel audit framework
> and extend the dm driver to log audit events in case of such
> integrity violations. Further, we also log construction and
> destruction of the device mappings.
> 
> We focus on dm-integrity and stacked dm-crypt devices for now.
> However, the helper functions to log audit messages should be
> applicable to dm-verity too.
> 
> The first patch introduce generic audit wrapper functions.
> The second patch makes use of the audit wrapper functions in the
> dm-integrity.c.
> The third patch uses the wrapper functions in dm-crypt.c.
> 
> The audit logs look like this if executing the following simple test:
> 
> # dd if=/dev/zero of=test.img bs=1M count=1024
> # losetup -f test.img
> # integritysetup -vD format --integrity sha256 -t 32 /dev/loop0
> # integritysetup open -D /dev/loop0 --integrity sha256 integritytest
> # integritysetup status integritytest
> # integritysetup close integritytest
> # integritysetup open -D /dev/loop0 --integrity sha256 integritytest
> # integritysetup status integritytest
> # dd if=/dev/urandom of=/dev/loop0 bs=512 count=1 seek=100000
> # dd if=/dev/mapper/integritytest of=/dev/null
> 
> -------------------------
> audit.log from auditd
> 
> type=UNKNOWN[1336] msg=audit(1630425039.363:184): module=integrity op=ctr ppid=3807 pid=3819 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=3 comm="integritysetup" exe="/sbin/integritysetup" subj==unconfined dev=254:3 error_msg='success' res=1
> type=UNKNOWN[1336] msg=audit(1630425039.471:185): module=integrity op=dtr ppid=3807 pid=3819 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=3 comm="integritysetup" exe="/sbin/integritysetup" subj==unconfined dev=254:3 error_msg='success' res=1
> type=UNKNOWN[1336] msg=audit(1630425039.611:186): module=integrity op=ctr ppid=3807 pid=3819 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=3 comm="integritysetup" exe="/sbin/integritysetup" subj==unconfined dev=254:3 error_msg='success' res=1
> type=UNKNOWN[1336] msg=audit(1630425054.475:187): module=integrity op=dtr ppid=3807 pid=3819 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=3 comm="integritysetup" exe="/sbin/integritysetup" subj==unconfined dev=254:3 error_msg='success' res=1
> 
> type=UNKNOWN[1336] msg=audit(1630425073.171:191): module=integrity op=ctr ppid=3807 pid=3883 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=3 comm="integritysetup" exe="/sbin/integritysetup" subj==unconfined dev=254:3 error_msg='success' res=1
> 
> type=UNKNOWN[1336] msg=audit(1630425087.239:192): module=integrity op=dtr ppid=3807 pid=3902 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=3 comm="integritysetup" exe="/sbin/integritysetup" subj==unconfined dev=254:3 error_msg='success' res=1
> 
> type=UNKNOWN[1336] msg=audit(1630425093.755:193): module=integrity op=ctr ppid=3807 pid=3906 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=3 comm="integritysetup" exe="/sbin/integritysetup" subj==unconfined dev=254:3 error_msg='success' res=1
> 
> type=UNKNOWN[1337] msg=audit(1630425112.119:194): module=integrity op=integrity-checksum dev=254:3 sector=77480 res=0
> type=UNKNOWN[1337] msg=audit(1630425112.119:195): module=integrity op=integrity-checksum dev=254:3 sector=77480 res=0
> type=UNKNOWN[1337] msg=audit(1630425112.119:196): module=integrity op=integrity-checksum dev=254:3 sector=77480 res=0
> type=UNKNOWN[1337] msg=audit(1630425112.119:197): module=integrity op=integrity-checksum dev=254:3 sector=77480 res=0
> type=UNKNOWN[1337] msg=audit(1630425112.119:198): module=integrity op=integrity-checksum dev=254:3 sector=77480 res=0
> type=UNKNOWN[1337] msg=audit(1630425112.119:199): module=integrity op=integrity-checksum dev=254:3 sector=77480 res=0
> type=UNKNOWN[1337] msg=audit(1630425112.119:200): module=integrity op=integrity-checksum dev=254:3 sector=77480 res=0
> type=UNKNOWN[1337] msg=audit(1630425112.119:201): module=integrity op=integrity-checksum dev=254:3 sector=77480 res=0
> type=UNKNOWN[1337] msg=audit(1630425112.119:202): module=integrity op=integrity-checksum dev=254:3 sector=77480 res=0
> type=UNKNOWN[1337] msg=audit(1630425112.119:203): module=integrity op=integrity-checksum dev=254:3 sector=77480 res=0

Are these isolated records, or are they accompanied by a type=SYSCALL
record in your logs?

The reason I ask is that audit_log_task_info() is included in three of
the calling methods (dm_audit_log_{target,ctr,dtr}) which use a
combination of AUDIT_DM_CTRL/AUDIT_DM_EVENT type while the fourth
(dm_audit_log_bio) also uses one of the types above but does not include
audit_log_task_info().  If all these records are accompanied by SYSCALL
records, then the task info would be redundant (and might even conflict
if there's a bug).  Another minor oddity is the double "=" for the subj
field, which doesn't appear to be a bug in your code, but still puzzling.

Are those last 10 records expected to be identical other than event
serial number?

> v4 Changes:
> - Added comments on intended use of wrapper functions in dm-audit.h
> - dm_audit_log_bio(): Fixed missing '=' as spotted by Paul
> - dm_audit_log_ti(): Handle wrong audit_type as suggested by Paul
> 
> v3 Changes:
> - Use of two audit event types AUDIT_DM_EVENT und AUDIT_DM_CTRL
> - Additionaly use audit_log_task_info in case of AUDIT_DM_CTRL messages
> - Provide consistent fields per message type as suggested by Paul
> - Added sample events to commit message of [1/3] as suggested by Paul
> - Rebased on v5.14
> 
> v2 Changes:
> - Fixed compile errors if CONFIG_DM_AUDIT is not set
> - Fixed formatting and typos as suggested by Casey
> 
> Michael Weiß (3):
>   dm: introduce audit event module for device mapper
>   dm integrity: log audit events for dm-integrity target
>   dm crypt: log aead integrity violations to audit subsystem
> 
>  drivers/md/Kconfig         | 10 +++++
>  drivers/md/Makefile        |  4 ++
>  drivers/md/dm-audit.c      | 84 ++++++++++++++++++++++++++++++++++++++
>  drivers/md/dm-audit.h      | 66 ++++++++++++++++++++++++++++++
>  drivers/md/dm-crypt.c      | 22 ++++++++--
>  drivers/md/dm-integrity.c  | 25 ++++++++++--
>  include/uapi/linux/audit.h |  2 +
>  7 files changed, 205 insertions(+), 8 deletions(-)
>  create mode 100644 drivers/md/dm-audit.c
>  create mode 100644 drivers/md/dm-audit.h
> 
> -- 
> 2.20.1
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://listman.redhat.com/mailman/listinfo/linux-audit

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635


  parent reply	other threads:[~2021-09-08  1:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-04  9:59 Michael Weiß
2021-09-04  9:59 ` [PATCH v4 1/3] dm: introduce audit event module for device mapper Michael Weiß
2021-09-04  9:59 ` [PATCH v4 2/3] dm integrity: log audit events for dm-integrity target Michael Weiß
2021-09-04  9:59 ` [PATCH v4 3/3] dm crypt: log aead integrity violations to audit subsystem Michael Weiß
2021-09-08  0:59 ` Richard Guy Briggs [this message]
2021-09-08  8:26   ` [PATCH v4 0/3] dm: audit event logging Weiß, Michael
2021-09-08 13:16     ` Richard Guy Briggs
2021-09-08 15:39       ` Steve Grubb
2021-09-12  9:38       ` Weiß, Michael

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=20210908005942.GJ490529@madcap2.tricolour.ca \
    --to=rgb@redhat.com \
    --cc=agk@redhat.com \
    --cc=casey@schaufler-ca.com \
    --cc=dm-devel@redhat.com \
    --cc=eparis@redhat.com \
    --cc=linux-audit@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=michael.weiss@aisec.fraunhofer.de \
    --cc=paul@paul-moore.com \
    --cc=snitzer@redhat.com \
    --cc=song@kernel.org \
    --subject='Re: [PATCH v4 0/3] dm: audit event logging' \
    /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

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