lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YqKGcdM3t5gjqBpq@sol.localdomain>
Date:   Thu, 9 Jun 2022 16:46:57 -0700
From:   Eric Biggers <ebiggers@...nel.org>
To:     Deven Bowers <deven.desai@...ux.microsoft.com>
Cc:     corbet@....net, zohar@...ux.ibm.com, jmorris@...ei.org,
        serge@...lyn.com, tytso@....edu, axboe@...nel.dk, agk@...hat.com,
        snitzer@...nel.org, eparis@...hat.com, paul@...l-moore.com,
        linux-doc@...r.kernel.org, linux-integrity@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        linux-fscrypt@...r.kernel.org, linux-block@...r.kernel.org,
        dm-devel@...hat.com, linux-audit@...hat.com,
        roberto.sassu@...wei.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v8 13/17] fsverity: consume builtin signature via LSM
 hook

On Wed, Jun 08, 2022 at 12:01:25PM -0700, Deven Bowers wrote:
> From: Fan Wu <wufan@...ux.microsoft.com>
> 
> fsverity represents a mechanism to support both integrity and
> authenticity protection of a file, supporting both signed and unsigned
> digests.
> 
> An LSM which controls access to a resource based on authenticity and
> integrity of said resource, can then use this data to make an informed
> decision on the authorization (provided by the LSM's policy) of said
> claim.
> 
> This effectively allows the extension of a policy enforcement layer in
> LSM for fsverity, allowing for more granular control of how a
> particular authenticity claim can be used. For example, "all (built-in)
> signed fsverity files should be allowed to execute, but only these
> hashes are allowed to be loaded as kernel modules".
> 
> This enforcement must be done in kernel space, as a userspace only
> solution would fail a simple litmus test: Download a self-contained
> malicious binary that never touches the userspace stack. This
> binary would still be able to execute.
> 
> Signed-off-by: Fan Wu <wufan@...ux.microsoft.com>
> Signed-off-by: Deven Bowers <deven.desai@...ux.microsoft.com>

The IMA support for fs-verity, which is now upstream, already does this (except
that IMA isn't an LSM).  It also doesn't rely on the fs-verity builtin
signatures, which shouldn't really be used.  Can you elaborate on how what
you're doing is better?

- Eric

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ