audit.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@kernel.org>
To: "Michael Weiß" <michael.weiss@aisec.fraunhofer.de>
Cc: Paul Moore <paul@paul-moore.com>,
	Richard Guy Briggs <rgb@redhat.com>,
	Mikulas Patocka <mpatocka@redhat.com>,
	gyroidos@aisec.fraunhofer.de, Alasdair Kergon <agk@redhat.com>,
	"maintainer:DEVICE-MAPPER (LVM)" <dm-devel@redhat.com>,
	Eric Paris <eparis@redhat.com>,
	open list <linux-kernel@vger.kernel.org>,
	"open list:AUDIT SUBSYSTEM" <audit@vger.kernel.org>
Subject: Re: dm verity: log audit events for dm-verity target
Date: Fri, 17 Mar 2023 17:29:23 -0400	[thread overview]
Message-ID: <ZBTbsx69kGXiKMIw@redhat.com> (raw)
In-Reply-To: <1f58acef-1e93-ed7a-3ad8-dd0927dacddc@aisec.fraunhofer.de>

On Fri, Mar 17 2023 at  4:00P -0400,
Michael Weiß <michael.weiss@aisec.fraunhofer.de> wrote:

> On 02.03.23 03:25, Paul Moore wrote:
> > On Wed, Mar 1, 2023 at 6:34 AM Michael Weiß
> > <michael.weiss@aisec.fraunhofer.de> wrote:
> >>
> >> dm-verity signals integrity violations by returning I/O errors
> >> to user space. To identify integrity violations by a controlling
> >> instance, the kernel audit subsystem can be used to emit audit
> >> events to user space. Analogous to dm-integrity, we also use the
> >> dm-audit submodule allowing to emit audit events on verification
> >> failures of metadata and data blocks as well as if max corrupted
> >> errors are reached.
> >>
> >> The construction and destruction of verity device mappings are
> >> also relevant for auditing a system. Thus, those events are also
> >> logged as audit events.
> >>
> >> We tested this by starting a container with the container manager
> >> (cmld) of GyroidOS which uses a dm-verity protected rootfs image
> >> root.img mapped to /dev/mapper/<uuid>-root. We than manipulated
> >> one block in the underlying image file and reading it from the
> >> protected mapper device again and again until we reach the max
> >> corrupted errors like this:
> >>
> >>   dd if=/dev/urandom of=root.img bs=512 count=1 seek=1000
> >>   for i in range {1..101}; do \
> >>     dd if=/dev/mapper/<uuid>-root of=/dev/null bs=4096 \
> >>        count=1 skip=1000 \
> >>   done
> >>
> >> The resulting audit log looks as follows:
> >>
> >>   type=DM_CTRL msg=audit(1677618791.876:962):
> >>     module=verity op=ctr ppid=4876 pid=29102 auid=0 uid=0 gid=0
> >>     euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=44
> >>     comm="cmld" exe="/usr/sbin/cml/cmld" subj=unconfined
> >>     dev=254:3 error_msg='success' res=1
> >>
> >>   type=DM_EVENT msg=audit(1677619463.786:1074): module=verity
> >>     op=verify-data dev=7:0 sector=1000 res=0
> >>   ...
> >>   type=DM_EVENT msg=audit(1677619596.727:1162): module=verity
> >>     op=verify-data dev=7:0 sector=1000 res=0
> >>
> >>   type=DM_EVENT msg=audit(1677619596.731:1163): module=verity
> >>     op=max-corrupted-errors dev=254:3 sector=? res=0
> >>
> >> Signed-off-by: Michael Weiß <michael.weiss@aisec.fraunhofer.de>
> >> ---
> >>  drivers/md/dm-verity-target.c | 20 ++++++++++++++++++--
> >>  1 file changed, 18 insertions(+), 2 deletions(-)
> > 
> > This looks reasonable to me from an audit perspective.
> > 
> > Acked-by: Paul Moore <paul@paul-moore.com>
> 
> Hi Mike, since Paul already gave his ack from audit perspective,
> do you pick this up? Or is there anything which I can improve from device
> mapper side?

Looks fine, but I haven't started a 6.4 branch yet. I'll pick this up
from dm-devel's patchwork when I do.

Mike

      reply	other threads:[~2023-03-17 21:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230301113415.47664-1-michael.weiss@aisec.fraunhofer.de>
     [not found] ` <CAHC9VhQ_zvTqck4A7HvqH2rcwxuato_9nVWMk_Yf=ip3q9omgA@mail.gmail.com>
2023-03-17  8:00   ` [PATCH] dm verity: log audit events for dm-verity target Michael Weiß
2023-03-17 21:29     ` Mike Snitzer [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=ZBTbsx69kGXiKMIw@redhat.com \
    --to=snitzer@kernel.org \
    --cc=agk@redhat.com \
    --cc=audit@vger.kernel.org \
    --cc=dm-devel@redhat.com \
    --cc=eparis@redhat.com \
    --cc=gyroidos@aisec.fraunhofer.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.weiss@aisec.fraunhofer.de \
    --cc=mpatocka@redhat.com \
    --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).