On Sat, Aug 14, 2021 at 2:34 PM Michael Weiß
<michael.weiss@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx>
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.
> ---
> 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@xxxxxxxxxxxxxxxxxxx>
> + */
> +
> +#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"
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.
--
paul moore
www.paul-moore.com
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
