linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Weiß, Michael" <michael.weiss@aisec.fraunhofer.de>
To: "paul@paul-moore.com" <paul@paul-moore.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-audit@redhat.com" <linux-audit@redhat.com>,
	"casey@schaufler-ca.com" <casey@schaufler-ca.com>,
	"agk@redhat.com" <agk@redhat.com>,
	"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>,
	"song@kernel.org" <song@kernel.org>,
	"eparis@redhat.com" <eparis@redhat.com>,
	"snitzer@redhat.com" <snitzer@redhat.com>,
	"dm-devel@redhat.com" <dm-devel@redhat.com>
Subject: Re: [PATCH v2 1/3] dm: introduce audit event module for device mapper
Date: Thu, 19 Aug 2021 19:29:03 +0000	[thread overview]
Message-ID: <67990d4f1ddc277a4444d329ea3623775616aa31.camel@aisec.fraunhofer.de> (raw)
In-Reply-To: <CAHC9VhRB1iviuOyeqi3L4DC8LNfnkz1HXC3hdqNvqm2sZQYXMQ@mail.gmail.com>

On Wed, 2021-08-18 at 14:59 -0400, Paul Moore wrote:
> On Sat, Aug 14, 2021 at 2:34 PM Michael Weiß
> <michael.weiss@aisec.fraunhofer.de> wrote:
> > To be able to send auditing events to user space, we introduce
> > a generic dm-audit module. It provides helper functions to emit
> > audit events through the kernel audit subsystem. We claim the
> > AUDIT_DM type=1336 out of the audit event messages range in the
> > corresponding userspace api in 'include/uapi/linux/audit.h' for
> > those events.
> > 
> > Following commits to device mapper targets actually will make
> > use of this to emit those events in relevant cases.
> > 
> > Signed-off-by: Michael Weiß <michael.weiss@aisec.fraunhofer.de>
> 
> Hi Michael,
> 
> You went into more detail in your patchset cover letter, e.g. example
> audit records, which I think would be helpful here in the commit
> description so we have it as part of the git log.  I don't want to
> discourage you from writing cover letters, but don't forget that the
> cover letters can be lost to the ether after a couple of years whereas
> the git log has a much longer lifetime (we hope!) and a tighter
> binding to the related code.

Hi Paul,

at first thank you for your comments.
I see your point and I will respect that in providing the next version of
this patch-set.

> 
> > ---
> >  drivers/md/Kconfig         | 10 +++++++
> >  drivers/md/Makefile        |  4 +++
> >  drivers/md/dm-audit.c      | 59 ++++++++++++++++++++++++++++++++++++++
> >  drivers/md/dm-audit.h      | 33 +++++++++++++++++++++
> >  include/uapi/linux/audit.h |  1 +
> >  5 files changed, 107 insertions(+)
> >  create mode 100644 drivers/md/dm-audit.c
> >  create mode 100644 drivers/md/dm-audit.h
> > 
> > diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
> > index 0602e82a9516..48adbec12148 100644
> > --- a/drivers/md/Kconfig
> > +++ b/drivers/md/Kconfig
> > @@ -608,6 +608,7 @@ config DM_INTEGRITY
> >         select CRYPTO
> >         select CRYPTO_SKCIPHER
> >         select ASYNC_XOR
> > +       select DM_AUDIT if AUDIT
> >         help
> >           This device-mapper target emulates a block device that has
> >           additional per-sector tags that can be used for storing
> > @@ -640,4 +641,13 @@ config DM_ZONED
> > 
> >           If unsure, say N.
> > 
> > +config DM_AUDIT
> > +       bool "DM audit events"
> > +       depends on AUDIT
> > +       help
> > +         Generate audit events for device-mapper.
> > +
> > +         Enables audit logging of several security relevant events in the
> > +         particular device-mapper targets, especially the integrity target.
> > +
> >  endif # MD
> > diff --git a/drivers/md/Makefile b/drivers/md/Makefile
> > index a74aaf8b1445..4cd47623c742 100644
> > --- a/drivers/md/Makefile
> > +++ b/drivers/md/Makefile
> > @@ -103,3 +103,7 @@ endif
> >  ifeq ($(CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG),y)
> >  dm-verity-objs                 += dm-verity-verify-sig.o
> >  endif
> > +
> > +ifeq ($(CONFIG_DM_AUDIT),y)
> > +dm-mod-objs                            += dm-audit.o
> > +endif
> > diff --git a/drivers/md/dm-audit.c b/drivers/md/dm-audit.c
> > new file mode 100644
> > index 000000000000..c7e5824821bb
> > --- /dev/null
> > +++ b/drivers/md/dm-audit.c
> > @@ -0,0 +1,59 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Creating audit records for mapped devices.
> > + *
> > + * Copyright (C) 2021 Fraunhofer AISEC. All rights reserved.
> > + *
> > + * Authors: Michael Weiß <michael.weiss@aisec.fraunhofer.de>
> > + */
> > +
> > +#include <linux/audit.h>
> > +#include <linux/module.h>
> > +#include <linux/device-mapper.h>
> > +#include <linux/bio.h>
> > +#include <linux/blkdev.h>
> > +
> > +#include "dm-audit.h"
> > +#include "dm-core.h"
> > +
> > +void dm_audit_log_bio(const char *dm_msg_prefix, const char *op,
> > +                     struct bio *bio, sector_t sector, int result)
> > +{
> > +       struct audit_buffer *ab;
> > +
> > +       if (audit_enabled == AUDIT_OFF)
> > +               return;
> > +
> > +       ab = audit_log_start(audit_context(), GFP_KERNEL, AUDIT_DM);
> > +       if (unlikely(!ab))
> > +               return;
> > +
> > +       audit_log_format(ab, "module=%s dev=%d:%d op=%s sector=%llu res=%d",
> > +                        dm_msg_prefix, MAJOR(bio->bi_bdev->bd_dev),
> > +                        MINOR(bio->bi_bdev->bd_dev), op, sector, result);
> > +       audit_log_end(ab);
> > +}
> > +EXPORT_SYMBOL_GPL(dm_audit_log_bio);
> > +
> > +void dm_audit_log_target(const char *dm_msg_prefix, const char *op,
> > +                        struct dm_target *ti, int result)
> > +{
> > +       struct audit_buffer *ab;
> > +       struct mapped_device *md = dm_table_get_md(ti->table);
> > +
> > +       if (audit_enabled == AUDIT_OFF)
> > +               return;
> > +
> > +       ab = audit_log_start(audit_context(), GFP_KERNEL, AUDIT_DM);
> > +       if (unlikely(!ab))
> > +               return;
> > +
> > +       audit_log_format(ab, "module=%s dev=%s op=%s",
> > +                        dm_msg_prefix, dm_device_name(md), op);
> > +
> > +       if (!result && !strcmp("ctr", op))
> > +               audit_log_format(ab, " error_msg='%s'", ti->error);
> > +       audit_log_format(ab, " res=%d", result);
> > +       audit_log_end(ab);
> > +}
> 
> Generally speaking we try to keep a consistent format and ordering
> within a given audit record type.  However you appear to have at least
> three different formats for the AUDIT_DM record in this patch:
> 
>   "... module=%s dev=%d:%d op=%s sector=%llu res=%d"
>   "... module=%s dev=%s op=%s error_msg='%s' res=%d"
>   "... module=%s dev=%s op=%s res=%d"
> 
> The first thing that jumps out is that some fields, e.g. "sector", are
> not always present in the record; we typically handle this by using a
> "?" for the field value in those cases where you would otherwise drop
> the field from the record, for example the following record:
> 
>   "... module=%s dev=%s op=%s res=%d"
> 
> ... would be rewritten like this:
> 
>   "... module=%s dev=%s op=%s sector=? res=%d"

Well, I didn't know that.
For target creation and destruction a sector is not relevant.
So would it also be an option for you if we just define two different
type of messages like this in audit.h?

#define AUDIT_DM_CTRL           1336    /* Device Mapper target control */
#define AUDIT_DM_EVENT		1337	/* Device Mapper events */

> 
> The second thing that I noticed is that the "dev" field changes from a
> "major:minor" number representation to an arbitrary string value, e.g.
> "dev=%s".  This generally isn't something we do with audit records,
> please stick to a single representation for a given audit
> record-type/field combination.

dm_device_name(md) already does provide a major:minor in string
representation, that is why I used it
directly with dev=%s
and in the bio case build it up manually out of major and minor
of the bdev.

I see two options here to be more clear on this in the code.
First, just provide a
comment or second use the major minor directly from
dm_disk(md)->major, dm_disk(md)->first_minor.

I'm not sure what's better here.


Thanks,
Michael

  reply	other threads:[~2021-08-19 19:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-14 18:33 [PATCH v2 0/3] dm: audit event logging Michael Weiß
2021-08-14 18:33 ` [PATCH v2 1/3] dm: introduce audit event module for device mapper Michael Weiß
2021-08-18 18:59   ` Paul Moore
2021-08-19 19:29     ` Weiß, Michael [this message]
2021-08-14 18:33 ` [PATCH v2 2/3] dm integrity: log audit events for dm-integrity target Michael Weiß
2021-08-14 18:33 ` [PATCH v2 3/3] dm crypt: log aead integrity violations to audit subsystem Michael Weiß

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=67990d4f1ddc277a4444d329ea3623775616aa31.camel@aisec.fraunhofer.de \
    --to=michael.weiss@aisec.fraunhofer.de \
    --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=paul@paul-moore.com \
    --cc=snitzer@redhat.com \
    --cc=song@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).