* Re: [PATCH v2 0/6] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
From: Ahmad Fatoum @ 2021-07-14 6:36 UTC (permalink / raw)
To: Jarkko Sakkinen, Horia Geantă, Mimi Zohar, Aymen Sghaier,
Herbert Xu, David S. Miller, James Bottomley
Cc: Jan Luebbe, Udit Agarwal, Sumit Garg, David Gstir, Eric Biggers,
Franck LENORMAND, Richard Weinberger, James Morris, linux-kernel,
David Howells, linux-security-module, keyrings, linux-crypto,
kernel, linux-integrity, Steffen Trumtrar, Serge E. Hallyn
In-Reply-To: <cover.1dfbb73645d917b3c76d01290804a3410bd9932e.1624364386.git-series.a.fatoum@pengutronix.de>
Dear Trusted Keys and CAAM maintainers/reviewers,
On 22.06.21 14:37, Ahmad Fatoum wrote:
> The first three patches are new and are applicable regardless of this
> series, but the rest won't apply cleanly without them. I chose to
> include them this time, but I can split them up for v3 if that's
> preferred.
>
> v1 -> v2:
> - Added new commit to make trusted key Kconfig option independent
> of TPM and added new Kconfig file and symbols for trusted keys
> - Add new commit for importing existing key material (Jan)
> - Allow users to force use of kernel RNG (Jarkko)
> - Enforce maximum keymod size (Horia)
> - Use append_seq_(in|out)_ptr_intlen instead of append_seq_(in|out)_ptr
> (Horia)
> - Make blobifier handle private to CAAM glue code file (Horia)
> - Extend trusted keys documentation for CAAM
> - Rebased on v5.12-rc7 and updated cover letter:
>
> The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core
> built into many newer i.MX and QorIQ SoCs by NXP.
>
> Its blob mechanism can AES encrypt/decrypt user data using a unique
> never-disclosed device-specific key.
>
> There has been multiple discussions on how to represent this within the kernel:
>
> The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core
> built into many newer i.MX and QorIQ SoCs by NXP.
>
> Its blob mechanism can AES encrypt/decrypt user data using a unique
> never-disclosed device-specific key. There has been multiple
> discussions on how to represent this within the kernel:
>
> - [RFC] crypto: caam - add red blobifier
> Steffen implemented[1] a PoC sysfs driver to start a discussion on how to
> best integrate the blob mechanism.
> Mimi suggested that it could be used to implement trusted keys.
> Trusted keys back then were a TPM-only feature.
>
> - security/keys/secure_key: Adds the secure key support based on CAAM.
> Udit added[2] a new "secure" key type with the CAAM as backend. The key
> material stays within the kernel only.
> Mimi and James agreed that this needs a generic interface, not specific
> to CAAM. Mimi suggested trusted keys. Jan noted that this could serve as
> basis for TEE-backed keys.
>
> - [RFC] drivers: crypto: caam: key: Add caam_tk key type
> Franck added[3] a new "caam_tk" key type based on Udit's work. This time
> it uses CAAM "black blobs" instead of "red blobs", so key material stays
> within the CAAM and isn't exposed to kernel in plaintext.
> James voiced the opinion that there should be just one user-facing generic
> wrap/unwrap key type with multiple possible handlers.
> David suggested trusted keys.
>
> - Introduce TEE based Trusted Keys support
> Sumit reworked[4] trusted keys to support multiple possible backends with
> one chosen at boot time and added a new TEE backend along with TPM.
> This now sits in Jarkko's master branch to be sent out for v5.13
>
> This patch series builds on top of Sumit's rework to have the CAAM as yet another
> trusted key backend.
>
> The CAAM bits are based on Steffen's initial patch from 2015. His work had been
> used in the field for some years now, so I preferred not to deviate too much from it.
>
> This series has been tested with dmcrypt[5] on an i.MX6DL.
>
> Looking forward to your feedback.
Gentle Ping.
> Cheers,
> Ahmad
>
> [1]: https://lore.kernel.org/linux-crypto/1447082306-19946-2-git-send-email-s.trumtrar@pengutronix.de/
> [2]: https://lore.kernel.org/linux-integrity/20180723111432.26830-1-udit.agarwal@nxp.com/
> [3]: https://lore.kernel.org/lkml/1551456599-10603-2-git-send-email-franck.lenormand@nxp.com/
> [4]: https://lore.kernel.org/lkml/1604419306-26105-1-git-send-email-sumit.garg@linaro.org/
> [5]: https://lore.kernel.org/linux-integrity/20210122084321.24012-2-a.fatoum@pengutronix.de/
>
> ---
> To: Jarkko Sakkinen <jarkko@kernel.org>
> To: "Horia Geantă" <horia.geanta@nxp.com>
> To: Mimi Zohar <zohar@linux.ibm.com>
> To: Aymen Sghaier <aymen.sghaier@nxp.com>
> To: Herbert Xu <herbert@gondor.apana.org.au>
> To: "David S. Miller" <davem@davemloft.net>
> To: James Bottomley <jejb@linux.ibm.com>
> Cc: David Howells <dhowells@redhat.com>
> Cc: James Morris <jmorris@namei.org>
> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> Cc: Udit Agarwal <udit.agarwal@nxp.com>
> Cc: Jan Luebbe <j.luebbe@pengutronix.de>
> Cc: David Gstir <david@sigma-star.at>
> Cc: Eric Biggers <ebiggers@kernel.org>
> Cc: Richard Weinberger <richard@nod.at>
> Cc: Franck LENORMAND <franck.lenormand@nxp.com>
> Cc: Sumit Garg <sumit.garg@linaro.org>
> Cc: linux-integrity@vger.kernel.org
> Cc: keyrings@vger.kernel.org
> Cc: linux-crypto@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-security-module@vger.kernel.org
>
> Ahmad Fatoum (6):
> KEYS: trusted: allow use of TEE as backend without TCG_TPM support
> KEYS: trusted: Allow import from existing key material for development
> KEYS: trusted: allow users to use kernel RNG for key material
> KEYS: trusted: allow trust sources to use kernel RNG for key material
> crypto: caam - add in-kernel interface for blob generator
> KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
>
> Documentation/admin-guide/kernel-parameters.txt | 8 +-
> Documentation/security/keys/trusted-encrypted.rst | 74 ++++-
> drivers/crypto/caam/Kconfig | 3 +-
> drivers/crypto/caam/Makefile | 1 +-
> drivers/crypto/caam/blob_gen.c | 230 +++++++++++++++-
> include/keys/trusted-type.h | 2 +-
> include/keys/trusted_caam.h | 11 +-
> include/soc/fsl/caam-blob.h | 56 ++++-
> security/keys/Kconfig | 14 +-
> security/keys/trusted-keys/Kconfig | 49 +++-
> security/keys/trusted-keys/Makefile | 10 +-
> security/keys/trusted-keys/trusted_caam.c | 74 +++++-
> security/keys/trusted-keys/trusted_core.c | 48 ++-
> 13 files changed, 554 insertions(+), 26 deletions(-)
> create mode 100644 drivers/crypto/caam/blob_gen.c
> create mode 100644 include/keys/trusted_caam.h
> create mode 100644 include/soc/fsl/caam-blob.h
> create mode 100644 security/keys/trusted-keys/Kconfig
> create mode 100644 security/keys/trusted-keys/trusted_caam.c
>
> base-commit: 13311e74253fe64329390df80bed3f07314ddd61
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [syzbot] memory leak in dev_exception_add
From: syzbot @ 2021-07-13 18:07 UTC (permalink / raw)
To: jmorris, linux-kernel, linux-security-module, serge,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 3dbdb38e Merge branch 'for-5.14' of git://git.kernel.org/p..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1518cffc300000
kernel config: https://syzkaller.appspot.com/x/.config?x=55ac6a927d7e3fe9
dashboard link: https://syzkaller.appspot.com/bug?extid=988c8a25ad1677559236
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1500e772300000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+988c8a25ad1677559236@syzkaller.appspotmail.com
BUG: memory leak
unreferenced object 0xffff88810d3a4300 (size 64):
comm "systemd", pid 1, jiffies 4294938536 (age 1351.150s)
hex dump (first 32 bytes):
01 00 00 00 03 00 00 00 02 00 07 00 00 00 00 00 ................
10 04 2b 0d 81 88 ff ff 22 01 00 00 00 00 ad de ..+.....".......
backtrace:
[<ffffffff81479633>] kmemdup+0x23/0x50 mm/util.c:128
[<ffffffff8217485f>] kmemdup include/linux/fortify-string.h:270 [inline]
[<ffffffff8217485f>] dev_exception_add+0x2f/0x160 security/device_cgroup.c:94
[<ffffffff82175812>] devcgroup_update_access security/device_cgroup.c:734 [inline]
[<ffffffff82175812>] devcgroup_access_write+0x8c2/0x9e0 security/device_cgroup.c:764
[<ffffffff813198bd>] cgroup_file_write+0x10d/0x260 kernel/cgroup/cgroup.c:3814
[<ffffffff81690535>] kernfs_fop_write_iter+0x1b5/0x270 fs/kernfs/file.c:296
[<ffffffff81560eb7>] call_write_iter include/linux/fs.h:2114 [inline]
[<ffffffff81560eb7>] new_sync_write+0x1d7/0x2b0 fs/read_write.c:518
[<ffffffff81564531>] vfs_write+0x351/0x400 fs/read_write.c:605
[<ffffffff8156481d>] ksys_write+0x9d/0x160 fs/read_write.c:658
[<ffffffff8439b235>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<ffffffff8439b235>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
[<ffffffff84400068>] entry_SYSCALL_64_after_hwframe+0x44/0xae
BUG: memory leak
unreferenced object 0xffff88810d2b0400 (size 64):
comm "systemd", pid 1, jiffies 4294938537 (age 1351.140s)
hex dump (first 32 bytes):
01 00 00 00 05 00 00 00 02 00 07 00 00 00 00 00 ................
90 ac 3b 0d 81 88 ff ff 22 01 00 00 00 00 ad de ..;.....".......
backtrace:
[<ffffffff81479633>] kmemdup+0x23/0x50 mm/util.c:128
[<ffffffff8217485f>] kmemdup include/linux/fortify-string.h:270 [inline]
[<ffffffff8217485f>] dev_exception_add+0x2f/0x160 security/device_cgroup.c:94
[<ffffffff82175812>] devcgroup_update_access security/device_cgroup.c:734 [inline]
[<ffffffff82175812>] devcgroup_access_write+0x8c2/0x9e0 security/device_cgroup.c:764
[<ffffffff813198bd>] cgroup_file_write+0x10d/0x260 kernel/cgroup/cgroup.c:3814
[<ffffffff81690535>] kernfs_fop_write_iter+0x1b5/0x270 fs/kernfs/file.c:296
[<ffffffff81560eb7>] call_write_iter include/linux/fs.h:2114 [inline]
[<ffffffff81560eb7>] new_sync_write+0x1d7/0x2b0 fs/read_write.c:518
[<ffffffff81564531>] vfs_write+0x351/0x400 fs/read_write.c:605
[<ffffffff8156481d>] ksys_write+0x9d/0x160 fs/read_write.c:658
[<ffffffff8439b235>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<ffffffff8439b235>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
[<ffffffff84400068>] entry_SYSCALL_64_after_hwframe+0x44/0xae
BUG: memory leak
unreferenced object 0xffff88810d3bac80 (size 64):
comm "systemd", pid 1, jiffies 4294938537 (age 1351.140s)
hex dump (first 32 bytes):
01 00 00 00 07 00 00 00 02 00 07 00 00 00 00 00 ................
50 84 31 0d 81 88 ff ff 22 01 00 00 00 00 ad de P.1.....".......
backtrace:
[<ffffffff81479633>] kmemdup+0x23/0x50 mm/util.c:128
[<ffffffff8217485f>] kmemdup include/linux/fortify-string.h:270 [inline]
[<ffffffff8217485f>] dev_exception_add+0x2f/0x160 security/device_cgroup.c:94
[<ffffffff82175812>] devcgroup_update_access security/device_cgroup.c:734 [inline]
[<ffffffff82175812>] devcgroup_access_write+0x8c2/0x9e0 security/device_cgroup.c:764
[<ffffffff813198bd>] cgroup_file_write+0x10d/0x260 kernel/cgroup/cgroup.c:3814
[<ffffffff81690535>] kernfs_fop_write_iter+0x1b5/0x270 fs/kernfs/file.c:296
[<ffffffff81560eb7>] call_write_iter include/linux/fs.h:2114 [inline]
[<ffffffff81560eb7>] new_sync_write+0x1d7/0x2b0 fs/read_write.c:518
[<ffffffff81564531>] vfs_write+0x351/0x400 fs/read_write.c:605
[<ffffffff8156481d>] ksys_write+0x9d/0x160 fs/read_write.c:658
[<ffffffff8439b235>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<ffffffff8439b235>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
[<ffffffff84400068>] entry_SYSCALL_64_after_hwframe+0x44/0xae
BUG: memory leak
unreferenced object 0xffff88810d318440 (size 64):
comm "systemd", pid 1, jiffies 4294938537 (age 1351.140s)
hex dump (first 32 bytes):
01 00 00 00 08 00 00 00 02 00 07 00 00 00 00 00 ................
d0 aa 3b 0d 81 88 ff ff 22 01 00 00 00 00 ad de ..;.....".......
backtrace:
[<ffffffff81479633>] kmemdup+0x23/0x50 mm/util.c:128
[<ffffffff8217485f>] kmemdup include/linux/fortify-string.h:270 [inline]
[<ffffffff8217485f>] dev_exception_add+0x2f/0x160 security/device_cgroup.c:94
[<ffffffff82175812>] devcgroup_update_access security/device_cgroup.c:734 [inline]
[<ffffffff82175812>] devcgroup_access_write+0x8c2/0x9e0 security/device_cgroup.c:764
[<ffffffff813198bd>] cgroup_file_write+0x10d/0x260 kernel/cgroup/cgroup.c:3814
[<ffffffff81690535>] kernfs_fop_write_iter+0x1b5/0x270 fs/kernfs/file.c:296
[<ffffffff81560eb7>] call_write_iter include/linux/fs.h:2114 [inline]
[<ffffffff81560eb7>] new_sync_write+0x1d7/0x2b0 fs/read_write.c:518
[<ffffffff81564531>] vfs_write+0x351/0x400 fs/read_write.c:605
[<ffffffff8156481d>] ksys_write+0x9d/0x160 fs/read_write.c:658
[<ffffffff8439b235>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<ffffffff8439b235>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
[<ffffffff84400068>] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 1363.912106][ C1]
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [Virtio-fs] [PATCH v2 1/1] xattr: Allow user.* xattr on symlink and special files
From: Casey Schaufler @ 2021-07-13 14:28 UTC (permalink / raw)
To: Greg Kurz
Cc: Vivek Goyal, Christian Brauner, gscrivan, tytso, miklos, selinux,
linux-kernel, virtio-fs, casey.schaufler, linux-security-module,
viro, Christoph Hellwig, linux-fsdevel, jack, Casey Schaufler
In-Reply-To: <20210712144849.121c948c@bahia.lan>
On 7/12/2021 5:49 AM, Greg Kurz wrote:
> On Fri, 9 Jul 2021 08:34:41 -0700
> Casey Schaufler <casey@schaufler-ca.com> wrote:
>
>> On 7/9/2021 8:27 AM, Vivek Goyal wrote:
>>> On Fri, Jul 09, 2021 at 11:19:15AM +0200, Christian Brauner wrote:
>>>> On Thu, Jul 08, 2021 at 01:57:38PM -0400, Vivek Goyal wrote:
>>>>> Currently user.* xattr are not allowed on symlink and special files.
>>>>>
>>>>> man xattr and recent discussion suggested that primary reason for this
>>>>> restriction is how file permissions for symlinks and special files
>>>>> are little different from regular files and directories.
>>>>>
>>>>> For symlinks, they are world readable/writable and if user xattr were
>>>>> to be permitted, it will allow unpriviliged users to dump a huge amount
>>>>> of user.* xattrs on symlinks without any control.
>>>>>
>>>>> For special files, permissions typically control capability to read/write
>>>>> from devices (and not necessarily from filesystem). So if a user can
>>>>> write to device (/dev/null), does not necessarily mean it should be allowed
>>>>> to write large number of user.* xattrs on the filesystem device node is
>>>>> residing in.
>>>>>
>>>>> This patch proposes to relax the restrictions a bit and allow file owner
>>>>> or priviliged user (CAP_FOWNER), to be able to read/write user.* xattrs
>>>>> on symlink and special files.
>>>>>
>>>>> virtiofs daemon has a need to store user.* xatrrs on all the files
>>>>> (including symlinks and special files), and currently that fails. This
>>>>> patch should help.
>>>>>
>>>>> Link: https://lore.kernel.org/linux-fsdevel/20210625191229.1752531-1-vgoyal@redhat.com/
>>>>> Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
>>>>> ---
>>>> Seems reasonable and useful.
>>>> Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
>>>>
>>>> One question, do all filesystem supporting xattrs deal with setting them
>>>> on symlinks/device files correctly?
>>> Wrote a simple bash script to do setfattr/getfattr user.foo xattr on
>>> symlink and device node on ext4, xfs and btrfs and it works fine.
>> How about nfs, tmpfs, overlayfs and/or some of the other less conventional
>> filesystems?
>>
> How about virtiofs then ? :-)
One of the "less conventional filesystems", surely.
�
^ permalink raw reply
* Re: [PATCH v2 1/1] xattr: Allow user.* xattr on symlink and special files
From: Casey Schaufler @ 2021-07-13 14:17 UTC (permalink / raw)
To: Vivek Goyal, J. Bruce Fields
Cc: Bruce Fields, Christian Brauner, linux-fsdevel, linux-kernel,
viro, virtio-fs, dwalsh, dgilbert, casey.schaufler,
linux-security-module, selinux, tytso, miklos, gscrivan, jack,
Christoph Hellwig, Casey Schaufler
In-Reply-To: <20210712174759.GA502004@redhat.com>
On 7/12/2021 10:47 AM, Vivek Goyal wrote:
> On Mon, Jul 12, 2021 at 11:41:06AM -0400, J. Bruce Fields wrote:
>> On Mon, Jul 12, 2021 at 10:02:47AM -0400, Vivek Goyal wrote:
>>> On Fri, Jul 09, 2021 at 04:10:16PM -0400, Bruce Fields wrote:
>>>> On Fri, Jul 9, 2021 at 1:59 PM Vivek Goyal <vgoyal@redhat.com> wrote:
>>>>> nfs seems to have some issues.
>>>> I'm not sure what the expected behavior is for nfs. All I have for
>>>> now is some generic troubleshooting ideas, sorry:
>>>>
>>>>> - I can set user.foo xattr on symlink and query it back using xattr name.
>>>>>
>>>>> getfattr -h -n user.foo foo-link.txt
>>>>>
>>>>> But when I try to dump all xattrs on this file, user.foo is being
>>>>> filtered out it looks like. Not sure why.
>>>> Logging into the server and seeing what's set there could help confirm
>>>> whether it's the client or server that's at fault. (Or watching the
>>>> traffic in wireshark; there are GET/SET/LISTXATTR ops that should be
>>>> easy to spot.)
>>>>
>>>>> - I can't set "user.foo" xattr on a device node on nfs and I get
>>>>> "Permission denied". I am assuming nfs server is returning this.
>>>> Wireshark should tell you whether it's the server or client doing that.
>>>>
>>>> The RFC is https://datatracker.ietf.org/doc/html/rfc8276, and I don't
>>>> see any explicit statement about what the server should do in the case
>>>> of symlinks or device nodes, but I do see "Any regular file or
>>>> directory may have a set of extended attributes", so that was clearly
>>>> the assumption. Also, NFS4ERR_WRONG_TYPE is listed as a possible
>>>> error return for the xattr ops. But on a quick skim I don't see any
>>>> explicit checks in the nfsd code, so I *think* it's just relying on
>>>> the vfs for any file type checks.
>>> Hi Bruce,
>>>
>>> Thanks for the response. I am just trying to do set a user.foo xattr on
>>> a device node on nfs.
>>>
>>> setfattr -n "user.foo" -v "bar" /mnt/nfs/test-dev
>>>
>>> and I get -EACCESS.
>>>
>>> I put some printk() statements and EACCESS is being returned from here.
>>>
>>> nfs4_xattr_set_nfs4_user() {
>>> if (!nfs_access_get_cached(inode, current_cred(), &cache, true)) {
>>> if (!(cache.mask & NFS_ACCESS_XAWRITE)) {
>>> return -EACCES;
>>> }
>>> }
>>> }
>>>
>>> Value of cache.mask=0xd at the time of error.
>> Looks like 0xd is what the server returns to access on a device node
>> with mode bits rw- for the caller.
>>
>> Commit c11d7fd1b317 "nfsd: take xattr bits into account for permission
>> checks" added the ACCESS_X* bits for regular files and directories but
>> not others.
>>
>> But you don't want to determine permission from the mode bits anyway,
>> you want it to depend on the owner,
> Thinking more about this part. Current implementation of my patch is
> effectively doing both the checks. It checks that you are owner or
> have CAP_FOWNER in xattr_permission() and then goes on to call
> inode_permission(). And that means file mode bits will also play a
> role. If caller does not have write permission on the file, it will
> be denied setxattr().
>
> If I don't call inode_permission(), and just return 0 right away for
> file owner (for symlinks and special files), then just being owner
> is enough to write user.* xattr. And then even security modules will
> not get a chance to block that operation.
That isn't going to fly. SELinux and Smack don't rely on ownership
as a criteria for access. Being the owner of a symlink conveys no
special privilege. The LSM must be consulted to determine if the
module's policy allows the access.
> IOW, if you are owner of
> a symlink or special file, you can write as many user.* xattr as you
> like and except quota does not look like anything else can block
> it. I am wondering if this approach is ok?
>
>
>
>> so I guess we should be calling
>> xattr_permission somewhere if we want that behavior.
>> The RFC assumes user xattrs are for regular files and directories,
>> without, as far as I can tell, actually explicitly forbidding them on
>> other objects. We should also raise this with the working group if we
>> want to increase the chances that you'll get the behavior you want on
>> non-Linux servers.
> Ok. I am hoping once this patch merges in some form, then I can
> follow it up with relevant working group.
>
>> The "User extended attributes" section of the xattr(7) man page will
>> need updating.
> Agreed. I will take care of that in a separate patch.
>
> Right now, I am not too sure if being owner should be the only check
> and I should skip calling inode_permission() entirely or not.
>
> Thanks
> Vivek
>
>> --b.
>>
^ permalink raw reply
* apparmor: global buffers spin lock may get contended
From: Sergey Senozhatsky @ 2021-07-13 13:19 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, John Johansen
Cc: Peter Zijlstra, Tomasz Figa, linux-kernel, linux-security-module
Hi,
We've notices that apparmor has switched from using per-CPU buffer pool
and per-CPU spin_lock to a global spin_lock in df323337e507a0009d3db1ea.
This seems to be causing some contention on our build machines (with
quite a bit of cores). Because that global spin lock is a part of the
stat() sys call (and perhaps some other)
E.g.
- 9.29% 0.00% clang++ [kernel.vmlinux]
- 9.28% entry_SYSCALL_64_after_hwframe
- 8.98% do_syscall_64
- 7.43% __do_sys_newlstat
- 7.43% vfs_statx
- 7.18% security_inode_getattr
- 7.15% apparmor_inode_getattr
- aa_path_perm
- 3.53% aa_get_buffer
- 3.47% _raw_spin_lock
3.44% native_queued_spin_lock_slowpath
- 3.49% aa_put_buffer.part.0
- 3.45% _raw_spin_lock
3.43% native_queued_spin_lock_slowpath
Can we fix this contention?
^ permalink raw reply
* Re: [PATCH v3 1/2] perf: Fix required permissions if sigtrap is requested
From: Peter Zijlstra @ 2021-07-13 9:48 UTC (permalink / raw)
To: Marco Elver
Cc: tglx, mingo, dvyukov, glider, kasan-dev, linux-kernel, mingo,
acme, mark.rutland, alexander.shishkin, jolsa, namhyung,
linux-perf-users, ebiederm, omosnace, serge,
linux-security-module, stable
In-Reply-To: <CANpmjNP7Z0mxaF+eYCtP1aabPcoh-0aDSOiW6FQsPkR8SbVwnA@mail.gmail.com>
On Mon, Jul 12, 2021 at 12:32:33PM +0200, Marco Elver wrote:
> It'd be good to get this sorted -- please take another look.
Thanks!
I'll queue them into perf/urgent.
^ permalink raw reply
* Re: [PATCH] tpm: ibmvtpm: Avoid error message when process gets signal while waiting
From: Nageswara Sastry @ 2021-07-13 5:03 UTC (permalink / raw)
To: Stefan Berger, peterhuewe, jarkko
Cc: jgg, linux-integrity, linux-security-module, linux-kernel,
Stefan Berger, Nayna Jain, George Wilson
In-Reply-To: <20210712162505.205943-1-stefanb@linux.vnet.ibm.com>
On 12/07/21 9:55 pm, Stefan Berger wrote:
> From: Stefan Berger <stefanb@linux.ibm.com>
>
> When rngd is run as root then lots of these types of message will appear
> in the kernel log if the TPM has been configure to provide random bytes:
>
> [ 7406.275163] tpm tpm0: tpm_transmit: tpm_recv: error -4
>
> The issue is caused by the following call that is interrupted while
> waiting for the TPM's response.
>
> sig = wait_event_interruptible(ibmvtpm->wq,
> !ibmvtpm->tpm_processing_cmd);
>
> The solution is to use wait_event() instead.
>
> To recreat the issue start rngd like this:
>
> sudo rngd -r /dev/hwrng -t
>
> Link: https://bugzilla.redhat.com/show_bug.cgi?id=1981473
> Fixes: 6674ff145eef ("tpm_ibmvtpm: properly handle interrupted packet receptions")
> Cc: Nayna Jain <nayna@linux.ibm.com>
> Cc: George Wilson <gcwilson@linux.ibm.com>
> Reported-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
> ---
> drivers/char/tpm/tpm_ibmvtpm.c | 13 ++++---------
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
> index 903604769de9..99b0442a5fdf 100644
> --- a/drivers/char/tpm/tpm_ibmvtpm.c
> +++ b/drivers/char/tpm/tpm_ibmvtpm.c
> @@ -106,16 +106,13 @@ static int tpm_ibmvtpm_recv(struct tpm_chip *chip, u8 *buf, size_t count)
> {
> struct ibmvtpm_dev *ibmvtpm = dev_get_drvdata(&chip->dev);
> u16 len;
> - int sig;
>
> if (!ibmvtpm->rtce_buf) {
> dev_err(ibmvtpm->dev, "ibmvtpm device is not ready\n");
> return 0;
> }
>
> - sig = wait_event_interruptible(ibmvtpm->wq, !ibmvtpm->tpm_processing_cmd);
> - if (sig)
> - return -EINTR;
> + wait_event(ibmvtpm->wq, !ibmvtpm->tpm_processing_cmd);
>
> len = ibmvtpm->res_len;
>
> @@ -206,7 +203,7 @@ static int tpm_ibmvtpm_send(struct tpm_chip *chip, u8 *buf, size_t count)
> {
> struct ibmvtpm_dev *ibmvtpm = dev_get_drvdata(&chip->dev);
> bool retry = true;
> - int rc, sig;
> + int rc;
>
> if (!ibmvtpm->rtce_buf) {
> dev_err(ibmvtpm->dev, "ibmvtpm device is not ready\n");
> @@ -224,9 +221,7 @@ static int tpm_ibmvtpm_send(struct tpm_chip *chip, u8 *buf, size_t count)
> dev_info(ibmvtpm->dev,
> "Need to wait for TPM to finish\n");
> /* wait for previous command to finish */
> - sig = wait_event_interruptible(ibmvtpm->wq, !ibmvtpm->tpm_processing_cmd);
> - if (sig)
> - return -EINTR;
> + wait_event(ibmvtpm->wq, !ibmvtpm->tpm_processing_cmd);
> }
>
> spin_lock(&ibmvtpm->rtce_lock);
> @@ -551,7 +546,7 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq *crq,
> /* len of the data in rtce buffer */
> ibmvtpm->res_len = be16_to_cpu(crq->len);
> ibmvtpm->tpm_processing_cmd = false;
> - wake_up_interruptible(&ibmvtpm->wq);
> + wake_up(&ibmvtpm->wq);
> return;
> default:
> return;
>
--
Thanks and Regards
R.Nageswara Sastry
^ permalink raw reply
* Re: [PATCH v3 3/3] ima: Add digest and digest_len params to the functions to measure a buffer
From: Paul Moore @ 2021-07-13 2:40 UTC (permalink / raw)
To: Roberto Sassu
Cc: zohar, Stephen Smalley, prsriva02, tusharsu, nramas,
linux-integrity, linux-security-module, linux-kernel, selinux
In-Reply-To: <20210705090922.3321178-4-roberto.sassu@huawei.com>
On Mon, Jul 5, 2021 at 5:09 AM Roberto Sassu <roberto.sassu@huawei.com> wrote:
>
> This patch adds the 'digest' and 'digest_len' parameters to
> ima_measure_critical_data() and process_buffer_measurement(), so that
> callers can get the digest of the passed buffer.
>
> These functions calculate the digest even if there is no suitable rule in
> the IMA policy and, in this case, they simply return 1 before generating a
> new measurement entry.
>
> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> ---
> include/linux/ima.h | 5 +--
> security/integrity/ima/ima.h | 2 +-
> security/integrity/ima/ima_appraise.c | 2 +-
> security/integrity/ima/ima_asymmetric_keys.c | 2 +-
> security/integrity/ima/ima_init.c | 3 +-
> security/integrity/ima/ima_main.c | 36 ++++++++++++++------
> security/integrity/ima/ima_queue_keys.c | 2 +-
> security/selinux/ima.c | 6 ++--
> 8 files changed, 39 insertions(+), 19 deletions(-)
The SELinux changes are trivial and fall into that
cross-subsystem-ACK-not-really-necessary category, but why not :)
For the SELinux bits:
Acked-by: Paul Moore <paul@paul-moore.com>
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH v3] lockdown,selinux: fix wrong subject in some SELinux lockdown checks
From: Paul Moore @ 2021-07-13 2:34 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Ondrej Mosnacek, linux-security-module, James Morris,
Steven Rostedt, Ingo Molnar, Steffen Klassert, Herbert Xu,
David S . Miller, Stephen Smalley, selinux, linuxppc-dev, x86,
linux-acpi, linux-cxl, linux-efi, linux-fsdevel, linux-pci,
linux-pm, linux-serial, bpf, netdev, kexec, linux-kernel,
Casey Schaufler
In-Reply-To: <8735tdiyc1.ffs@nanos.tec.linutronix.de>
On Sat, Jun 19, 2021 at 1:00 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> On Wed, Jun 16 2021 at 10:51, Ondrej Mosnacek wrote:
> > diff --git a/arch/x86/mm/testmmiotrace.c b/arch/x86/mm/testmmiotrace.c
> > index bda73cb7a044..c43a13241ae8 100644
> > --- a/arch/x86/mm/testmmiotrace.c
> > +++ b/arch/x86/mm/testmmiotrace.c
> > @@ -116,7 +116,7 @@ static void do_test_bulk_ioremapping(void)
> > static int __init init(void)
> > {
> > unsigned long size = (read_far) ? (8 << 20) : (16 << 10);
> > - int ret = security_locked_down(LOCKDOWN_MMIOTRACE);
> > + int ret = security_locked_down(current_cred(), LOCKDOWN_MMIOTRACE);
>
> I have no real objection to those patches, but it strikes me odd that
> out of the 62 changed places 58 have 'current_cred()' and 4 have NULL as
> argument.
>
> I can't see why this would ever end up with anything else than
> current_cred() or NULL and NULL being the 'special' case. So why not
> having security_locked_down_no_cred() and make current_cred() implicit
> for security_locked_down() which avoids most of the churn and just makes
> the special cases special. I might be missing something though.
Unfortunately it is not uncommon for kernel subsystems to add, move,
or otherwise play around with LSM hooks without checking with the LSM
folks; generally this is okay, but there have been a few problems in
the past and I try to keep that in mind when we are introducing new
hooks or modifying existing ones. If we have two LSM hooks for
roughly the same control point it has the potential to cause
confusion, e.g. do I use the "normal" or the "no_cred" version? What
if I don't want to pass a credential, can I just use "no_cred"? My
thinking with the single, always-pass-a-cred function is that callers
don't have to worry about choosing from multiple, similar hooks and
they know they need to pass a cred which hopefully gets them thinking
about what cred is appropriate. It's not foolproof, but I believe the
single hook approach will be less prone to accidents ... or so I hope
:)
--
paul moore
www.paul-moore.com
^ permalink raw reply
* [PATCH] LSM: add NULL check for kcalloc()
From: Austin Kim @ 2021-07-12 23:44 UTC (permalink / raw)
To: jmorris, serge, keescook
Cc: linux-security-module, linux-kernel, austin.kim, kernel-team,
austindh.kim
From: Austin Kim <austin.kim@lge.com>
kcalloc() may return NULL when memory allocation fails.
So it is necessary to add NULL check after the call to kcalloc() is made.
Signed-off-by: Austin Kim <austin.kim@lge.com>
---
security/security.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/security/security.c b/security/security.c
index 09533cbb7221..f885c9e9bc35 100644
--- a/security/security.c
+++ b/security/security.c
@@ -321,6 +321,8 @@ static void __init ordered_lsm_init(void)
ordered_lsms = kcalloc(LSM_COUNT + 1, sizeof(*ordered_lsms),
GFP_KERNEL);
+ if (ordered_lsms)
+ return;
if (chosen_lsm_order) {
if (chosen_major_lsm) {
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 1/1] xattr: Allow user.* xattr on symlink and special files
From: Vivek Goyal @ 2021-07-12 21:22 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Bruce Fields, Casey Schaufler, Christian Brauner, linux-fsdevel,
linux-kernel, viro, virtio-fs, dwalsh, dgilbert, casey.schaufler,
linux-security-module, selinux, tytso, miklos, gscrivan, jack,
Christoph Hellwig
In-Reply-To: <20210712193139.GA22997@fieldses.org>
On Mon, Jul 12, 2021 at 03:31:39PM -0400, J. Bruce Fields wrote:
> On Mon, Jul 12, 2021 at 01:47:59PM -0400, Vivek Goyal wrote:
> > On Mon, Jul 12, 2021 at 11:41:06AM -0400, J. Bruce Fields wrote:
> > > Looks like 0xd is what the server returns to access on a device node
> > > with mode bits rw- for the caller.
> > >
> > > Commit c11d7fd1b317 "nfsd: take xattr bits into account for permission
> > > checks" added the ACCESS_X* bits for regular files and directories but
> > > not others.
> > >
> > > But you don't want to determine permission from the mode bits anyway,
> > > you want it to depend on the owner,
> >
> > Thinking more about this part. Current implementation of my patch is
> > effectively doing both the checks. It checks that you are owner or
> > have CAP_FOWNER in xattr_permission() and then goes on to call
> > inode_permission(). And that means file mode bits will also play a
> > role. If caller does not have write permission on the file, it will
> > be denied setxattr().
> >
> > If I don't call inode_permission(), and just return 0 right away for
> > file owner (for symlinks and special files), then just being owner
> > is enough to write user.* xattr. And then even security modules will
> > not get a chance to block that operation. IOW, if you are owner of
> > a symlink or special file, you can write as many user.* xattr as you
> > like and except quota does not look like anything else can block
> > it. I am wondering if this approach is ok?
>
> Yeah, I'd expect security modules to get a say, and I wouldn't expect
> mode bits on device nodes to be useful for deciding whether it makes
> sense for xattrs to be readable or writeable.
Actually, calling inode_permission() for symlinks probably should be
fine.
Its the device node which is problematic. Because we started with the
assumption that mode bits there represent access writes for read/writing
to device (and not to the filesystem).
>
> But, I don't really know.
>
> Do we have any other use cases besides this case of storing security
> labels in user xattrs?
Storing security label was one example. In case of virtiofs, there is
a good chance that we will end up remapping all the guest xattrs and
prefix these with "user.virtiofsd".
fuse-overlay is another use case. They are storing real uid/gid in
user.* xattrs for files over NFS.
I think overlayfs can be another benefeciary in some form. Now there
is support for unpriviliged mouting of overlayfs from inside a user
namespace. And that uses xattrs "user.overlay" on upper files for
overlayfs specific metadata. Device nodes are not copied up. But
they might have an issue with symlinks. Miklos, will know more.
Thanks
Vivek
^ permalink raw reply
* Re: [PATCH v2 1/1] xattr: Allow user.* xattr on symlink and special files
From: J. Bruce Fields @ 2021-07-12 19:31 UTC (permalink / raw)
To: Vivek Goyal
Cc: Bruce Fields, Casey Schaufler, Christian Brauner, linux-fsdevel,
linux-kernel, viro, virtio-fs, dwalsh, dgilbert, casey.schaufler,
linux-security-module, selinux, tytso, miklos, gscrivan, jack,
Christoph Hellwig
In-Reply-To: <20210712174759.GA502004@redhat.com>
On Mon, Jul 12, 2021 at 01:47:59PM -0400, Vivek Goyal wrote:
> On Mon, Jul 12, 2021 at 11:41:06AM -0400, J. Bruce Fields wrote:
> > Looks like 0xd is what the server returns to access on a device node
> > with mode bits rw- for the caller.
> >
> > Commit c11d7fd1b317 "nfsd: take xattr bits into account for permission
> > checks" added the ACCESS_X* bits for regular files and directories but
> > not others.
> >
> > But you don't want to determine permission from the mode bits anyway,
> > you want it to depend on the owner,
>
> Thinking more about this part. Current implementation of my patch is
> effectively doing both the checks. It checks that you are owner or
> have CAP_FOWNER in xattr_permission() and then goes on to call
> inode_permission(). And that means file mode bits will also play a
> role. If caller does not have write permission on the file, it will
> be denied setxattr().
>
> If I don't call inode_permission(), and just return 0 right away for
> file owner (for symlinks and special files), then just being owner
> is enough to write user.* xattr. And then even security modules will
> not get a chance to block that operation. IOW, if you are owner of
> a symlink or special file, you can write as many user.* xattr as you
> like and except quota does not look like anything else can block
> it. I am wondering if this approach is ok?
Yeah, I'd expect security modules to get a say, and I wouldn't expect
mode bits on device nodes to be useful for deciding whether it makes
sense for xattrs to be readable or writeable.
But, I don't really know.
Do we have any other use cases besides this case of storing security
labels in user xattrs?
--b.
^ permalink raw reply
* Re: [PATCH v2 1/1] xattr: Allow user.* xattr on symlink and special files
From: Vivek Goyal @ 2021-07-12 17:50 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Casey Schaufler, Christian Brauner, linux-fsdevel, linux-kernel,
viro, virtio-fs, dwalsh, dgilbert, casey.schaufler,
linux-security-module, selinux, miklos, gscrivan, jack,
Christoph Hellwig
In-Reply-To: <YOizURuWJO9DYGGk@mit.edu>
On Fri, Jul 09, 2021 at 04:36:33PM -0400, Theodore Ts'o wrote:
> On Fri, Jul 09, 2021 at 08:34:41AM -0700, Casey Schaufler wrote:
> > >> One question, do all filesystem supporting xattrs deal with setting them
> > >> on symlinks/device files correctly?
> > > Wrote a simple bash script to do setfattr/getfattr user.foo xattr on
> > > symlink and device node on ext4, xfs and btrfs and it works fine.
> >
> > How about nfs, tmpfs, overlayfs and/or some of the other less conventional
> > filesystems?
>
> As a suggestion, perhaps you could take your bash script and turn it
> into an xfstests test so we can more easily test various file systems,
> both now and once the commit is accepted, to look for regressions?
Sounds good. I see there is already an xattr test (generic/062) which
is broken after my patch. Current test expects that user.* xattrs will
fail on symlink/special device.
I will probably have to query kernel version and modify test so that
expect failure before a certain version and success otherwise.
Thanks
Vivek
^ permalink raw reply
* Re: [PATCH v2 1/1] xattr: Allow user.* xattr on symlink and special files
From: Vivek Goyal @ 2021-07-12 17:47 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Bruce Fields, Casey Schaufler, Christian Brauner, linux-fsdevel,
linux-kernel, viro, virtio-fs, dwalsh, dgilbert, casey.schaufler,
linux-security-module, selinux, tytso, miklos, gscrivan, jack,
Christoph Hellwig
In-Reply-To: <20210712154106.GB18679@fieldses.org>
On Mon, Jul 12, 2021 at 11:41:06AM -0400, J. Bruce Fields wrote:
> On Mon, Jul 12, 2021 at 10:02:47AM -0400, Vivek Goyal wrote:
> > On Fri, Jul 09, 2021 at 04:10:16PM -0400, Bruce Fields wrote:
> > > On Fri, Jul 9, 2021 at 1:59 PM Vivek Goyal <vgoyal@redhat.com> wrote:
> > > > nfs seems to have some issues.
> > >
> > > I'm not sure what the expected behavior is for nfs. All I have for
> > > now is some generic troubleshooting ideas, sorry:
> > >
> > > > - I can set user.foo xattr on symlink and query it back using xattr name.
> > > >
> > > > getfattr -h -n user.foo foo-link.txt
> > > >
> > > > But when I try to dump all xattrs on this file, user.foo is being
> > > > filtered out it looks like. Not sure why.
> > >
> > > Logging into the server and seeing what's set there could help confirm
> > > whether it's the client or server that's at fault. (Or watching the
> > > traffic in wireshark; there are GET/SET/LISTXATTR ops that should be
> > > easy to spot.)
> > >
> > > > - I can't set "user.foo" xattr on a device node on nfs and I get
> > > > "Permission denied". I am assuming nfs server is returning this.
> > >
> > > Wireshark should tell you whether it's the server or client doing that.
> > >
> > > The RFC is https://datatracker.ietf.org/doc/html/rfc8276, and I don't
> > > see any explicit statement about what the server should do in the case
> > > of symlinks or device nodes, but I do see "Any regular file or
> > > directory may have a set of extended attributes", so that was clearly
> > > the assumption. Also, NFS4ERR_WRONG_TYPE is listed as a possible
> > > error return for the xattr ops. But on a quick skim I don't see any
> > > explicit checks in the nfsd code, so I *think* it's just relying on
> > > the vfs for any file type checks.
> >
> > Hi Bruce,
> >
> > Thanks for the response. I am just trying to do set a user.foo xattr on
> > a device node on nfs.
> >
> > setfattr -n "user.foo" -v "bar" /mnt/nfs/test-dev
> >
> > and I get -EACCESS.
> >
> > I put some printk() statements and EACCESS is being returned from here.
> >
> > nfs4_xattr_set_nfs4_user() {
> > if (!nfs_access_get_cached(inode, current_cred(), &cache, true)) {
> > if (!(cache.mask & NFS_ACCESS_XAWRITE)) {
> > return -EACCES;
> > }
> > }
> > }
> >
> > Value of cache.mask=0xd at the time of error.
>
> Looks like 0xd is what the server returns to access on a device node
> with mode bits rw- for the caller.
>
> Commit c11d7fd1b317 "nfsd: take xattr bits into account for permission
> checks" added the ACCESS_X* bits for regular files and directories but
> not others.
>
> But you don't want to determine permission from the mode bits anyway,
> you want it to depend on the owner,
Thinking more about this part. Current implementation of my patch is
effectively doing both the checks. It checks that you are owner or
have CAP_FOWNER in xattr_permission() and then goes on to call
inode_permission(). And that means file mode bits will also play a
role. If caller does not have write permission on the file, it will
be denied setxattr().
If I don't call inode_permission(), and just return 0 right away for
file owner (for symlinks and special files), then just being owner
is enough to write user.* xattr. And then even security modules will
not get a chance to block that operation. IOW, if you are owner of
a symlink or special file, you can write as many user.* xattr as you
like and except quota does not look like anything else can block
it. I am wondering if this approach is ok?
> so I guess we should be calling
> xattr_permission somewhere if we want that behavior.
>
> The RFC assumes user xattrs are for regular files and directories,
> without, as far as I can tell, actually explicitly forbidding them on
> other objects. We should also raise this with the working group if we
> want to increase the chances that you'll get the behavior you want on
> non-Linux servers.
Ok. I am hoping once this patch merges in some form, then I can
follow it up with relevant working group.
>
> The "User extended attributes" section of the xattr(7) man page will
> need updating.
Agreed. I will take care of that in a separate patch.
Right now, I am not too sure if being owner should be the only check
and I should skip calling inode_permission() entirely or not.
Thanks
Vivek
>
> --b.
>
^ permalink raw reply
* [PATCH v8 5/5] certs: Allow root user to append signed hashes to the blacklist keyring
From: Mickaël Salaün @ 2021-07-12 17:03 UTC (permalink / raw)
To: David Howells, David Woodhouse, Jarkko Sakkinen
Cc: Mickaël Salaün, David S . Miller, Eric Snowberg,
Herbert Xu, James Morris, Mickaël Salaün, Mimi Zohar,
Serge E . Hallyn, Tyler Hicks, keyrings, linux-crypto,
linux-integrity, linux-kernel, linux-security-module
In-Reply-To: <20210712170313.884724-1-mic@digikod.net>
From: Mickaël Salaün <mic@linux.microsoft.com>
Add a kernel option SYSTEM_BLACKLIST_AUTH_UPDATE to enable the root user
to dynamically add new keys to the blacklist keyring. This enables to
invalidate new certificates, either from being loaded in a keyring, or
from being trusted in a PKCS#7 certificate chain. This also enables to
add new file hashes to be denied by the integrity infrastructure.
Being able to untrust a certificate which could have normaly been
trusted is a sensitive operation. This is why adding new hashes to the
blacklist keyring is only allowed when these hashes are signed and
vouched by the builtin trusted keyring. A blacklist hash is stored as a
key description. The PKCS#7 signature of this description must be
provided as the key payload.
Marking a certificate as untrusted should be enforced while the system
is running. It is then forbiden to remove such blacklist keys.
Update blacklist keyring, blacklist key and revoked certificate access rights:
* allows the root user to search for a specific blacklisted hash, which
make sense because the descriptions are already viewable;
* forbids key update (blacklist and asymmetric ones);
* restricts kernel rights on the blacklist keyring to align with the
root user rights.
See help in tools/certs/print-cert-tbs-hash.sh .
Cc: David Howells <dhowells@redhat.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Eric Snowberg <eric.snowberg@oracle.com>
Cc: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com>
Link: https://lore.kernel.org/r/20210712170313.884724-6-mic@digikod.net
---
Changes since v6:
* Rebase on keys-cve-2020-26541-v3: commit ebd9c2ae369a ("integrity:
Load mokx variables into the blacklist keyring").
Changes since v5:
* Rebase on keys-next, fix Kconfig conflict, and update the asymmetric
key rights added to the blacklist keyring by the new
add_key_to_revocation_list(): align with blacklist key rights by
removing KEY_POS_WRITE as a safeguard, and add
KEY_ALLOC_BYPASS_RESTRICTION to not be subject to
restrict_link_for_blacklist() that only allows blacklist key types to
be added to the keyring.
* Change the return code for restrict_link_for_blacklist() from -EPERM
to -EOPNOTSUPP to align with asymmetric key keyrings.
Changes since v3:
* Update commit message for print-cert-tbs-hash.sh .
Changes since v2:
* Add comment for blacklist_key_instantiate().
---
certs/Kconfig | 10 +++++
certs/blacklist.c | 96 ++++++++++++++++++++++++++++++++++++-----------
2 files changed, 85 insertions(+), 21 deletions(-)
diff --git a/certs/Kconfig b/certs/Kconfig
index 0fbe184ceca5..e0e524b7eff9 100644
--- a/certs/Kconfig
+++ b/certs/Kconfig
@@ -103,4 +103,14 @@ config SYSTEM_REVOCATION_KEYS
containing X.509 certificates to be included in the default blacklist
keyring.
+config SYSTEM_BLACKLIST_AUTH_UPDATE
+ bool "Allow root to add signed blacklist keys"
+ depends on SYSTEM_BLACKLIST_KEYRING
+ depends on SYSTEM_DATA_VERIFICATION
+ help
+ If set, provide the ability to load new blacklist keys at run time if
+ they are signed and vouched by a certificate from the builtin trusted
+ keyring. The PKCS#7 signature of the description is set in the key
+ payload. Blacklist keys cannot be removed.
+
endmenu
diff --git a/certs/blacklist.c b/certs/blacklist.c
index b254c87ceb3a..486ce0dd8e9c 100644
--- a/certs/blacklist.c
+++ b/certs/blacklist.c
@@ -15,6 +15,7 @@
#include <linux/err.h>
#include <linux/seq_file.h>
#include <linux/uidgid.h>
+#include <linux/verification.h>
#include <keys/system_keyring.h>
#include "blacklist.h"
#include "common.h"
@@ -26,6 +27,9 @@
*/
#define MAX_HASH_LEN 128
+#define BLACKLIST_KEY_PERM (KEY_POS_SEARCH | KEY_POS_VIEW | \
+ KEY_USR_SEARCH | KEY_USR_VIEW)
+
static const char tbs_prefix[] = "tbs";
static const char bin_prefix[] = "bin";
@@ -80,19 +84,51 @@ static int blacklist_vet_description(const char *desc)
return 0;
}
-/*
- * The hash to be blacklisted is expected to be in the description. There will
- * be no payload.
- */
-static int blacklist_preparse(struct key_preparsed_payload *prep)
+static int blacklist_key_instantiate(struct key *key,
+ struct key_preparsed_payload *prep)
{
- if (prep->datalen > 0)
- return -EINVAL;
- return 0;
+#ifdef CONFIG_SYSTEM_BLACKLIST_AUTH_UPDATE
+ int err;
+#endif
+
+ /* Sets safe default permissions for keys loaded by user space. */
+ key->perm = BLACKLIST_KEY_PERM;
+
+ /*
+ * Skips the authentication step for builtin hashes, they are not
+ * signed but still trusted.
+ */
+ if (key->flags & (1 << KEY_FLAG_BUILTIN))
+ goto out;
+
+#ifdef CONFIG_SYSTEM_BLACKLIST_AUTH_UPDATE
+ /*
+ * Verifies the description's PKCS#7 signature against the builtin
+ * trusted keyring.
+ */
+ err = verify_pkcs7_signature(key->description,
+ strlen(key->description), prep->data, prep->datalen,
+ NULL, VERIFYING_UNSPECIFIED_SIGNATURE, NULL, NULL);
+ if (err)
+ return err;
+#else
+ /*
+ * It should not be possible to come here because the keyring doesn't
+ * have KEY_USR_WRITE and the only other way to call this function is
+ * for builtin hashes.
+ */
+ WARN_ON_ONCE(1);
+ return -EPERM;
+#endif
+
+out:
+ return generic_key_instantiate(key, prep);
}
-static void blacklist_free_preparse(struct key_preparsed_payload *prep)
+static int blacklist_key_update(struct key *key,
+ struct key_preparsed_payload *prep)
{
+ return -EPERM;
}
static void blacklist_describe(const struct key *key, struct seq_file *m)
@@ -103,9 +139,8 @@ static void blacklist_describe(const struct key *key, struct seq_file *m)
static struct key_type key_type_blacklist = {
.name = "blacklist",
.vet_description = blacklist_vet_description,
- .preparse = blacklist_preparse,
- .free_preparse = blacklist_free_preparse,
- .instantiate = generic_key_instantiate,
+ .instantiate = blacklist_key_instantiate,
+ .update = blacklist_key_update,
.describe = blacklist_describe,
};
@@ -154,8 +189,7 @@ static int mark_raw_hash_blacklisted(const char *hash)
hash,
NULL,
0,
- ((KEY_POS_ALL & ~KEY_POS_SETATTR) |
- KEY_USR_VIEW),
+ BLACKLIST_KEY_PERM,
KEY_ALLOC_NOT_IN_QUOTA |
KEY_ALLOC_BUILT_IN);
if (IS_ERR(key)) {
@@ -232,8 +266,10 @@ int add_key_to_revocation_list(const char *data, size_t size)
NULL,
data,
size,
- ((KEY_POS_ALL & ~KEY_POS_SETATTR) | KEY_USR_VIEW),
- KEY_ALLOC_NOT_IN_QUOTA | KEY_ALLOC_BUILT_IN);
+ KEY_POS_VIEW | KEY_POS_READ | KEY_POS_SEARCH
+ | KEY_USR_VIEW,
+ KEY_ALLOC_NOT_IN_QUOTA | KEY_ALLOC_BUILT_IN
+ | KEY_ALLOC_BYPASS_RESTRICTION);
if (IS_ERR(key)) {
pr_err("Problem with revocation key (%ld)\n", PTR_ERR(key));
@@ -260,25 +296,43 @@ int is_key_on_revocation_list(struct pkcs7_message *pkcs7)
}
#endif
+static int restrict_link_for_blacklist(struct key *dest_keyring,
+ const struct key_type *type, const union key_payload *payload,
+ struct key *restrict_key)
+{
+ if (type == &key_type_blacklist)
+ return 0;
+ return -EOPNOTSUPP;
+}
+
/*
* Initialise the blacklist
*/
static int __init blacklist_init(void)
{
const char *const *bl;
+ struct key_restriction *restriction;
if (register_key_type(&key_type_blacklist) < 0)
panic("Can't allocate system blacklist key type\n");
+ restriction = kzalloc(sizeof(*restriction), GFP_KERNEL);
+ if (!restriction)
+ panic("Can't allocate blacklist keyring restriction\n");
+ restriction->check = restrict_link_for_blacklist;
+
blacklist_keyring =
keyring_alloc(".blacklist",
GLOBAL_ROOT_UID, GLOBAL_ROOT_GID, current_cred(),
- (KEY_POS_ALL & ~KEY_POS_SETATTR) |
- KEY_USR_VIEW | KEY_USR_READ |
- KEY_USR_SEARCH,
- KEY_ALLOC_NOT_IN_QUOTA |
+ KEY_POS_VIEW | KEY_POS_READ | KEY_POS_SEARCH |
+ KEY_POS_WRITE |
+ KEY_USR_VIEW | KEY_USR_READ | KEY_USR_SEARCH
+#ifdef CONFIG_SYSTEM_BLACKLIST_AUTH_UPDATE
+ | KEY_USR_WRITE
+#endif
+ , KEY_ALLOC_NOT_IN_QUOTA |
KEY_ALLOC_SET_KEEP,
- NULL, NULL);
+ restriction, NULL);
if (IS_ERR(blacklist_keyring))
panic("Can't allocate system blacklist keyring\n");
--
2.32.0
^ permalink raw reply related
* [PATCH v8 4/5] certs: Factor out the blacklist hash creation
From: Mickaël Salaün @ 2021-07-12 17:03 UTC (permalink / raw)
To: David Howells, David Woodhouse, Jarkko Sakkinen
Cc: Mickaël Salaün, David S . Miller, Eric Snowberg,
Herbert Xu, James Morris, Mickaël Salaün, Mimi Zohar,
Serge E . Hallyn, Tyler Hicks, keyrings, linux-crypto,
linux-integrity, linux-kernel, linux-security-module
In-Reply-To: <20210712170313.884724-1-mic@digikod.net>
From: Mickaël Salaün <mic@linux.microsoft.com>
Factor out the blacklist hash creation with the get_raw_hash() helper.
This also centralize the "tbs" and "bin" prefixes and make them private,
which help to manage them consistently.
Cc: David Howells <dhowells@redhat.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Eric Snowberg <eric.snowberg@oracle.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com>
Link: https://lore.kernel.org/r/20210712170313.884724-5-mic@digikod.net
---
Changes since v6:
* Rebase on keys-cve-2020-26541-v3: commit ebd9c2ae369a ("integrity:
Load mokx variables into the blacklist keyring").
Changes since v5:
* Rebase on keys-next and fix conflict as previously done by David
Howells.
* Fix missing part to effectively handle UEFI DBX blacklisting.
* Remove Jarkko's Acked-by because of the above changes.
Changes since v2:
* Add Jarkko's Acked-by.
---
certs/blacklist.c | 76 ++++++++++++++-----
crypto/asymmetric_keys/x509_public_key.c | 3 +-
include/keys/system_keyring.h | 14 +++-
.../platform_certs/keyring_handler.c | 26 +------
4 files changed, 73 insertions(+), 46 deletions(-)
diff --git a/certs/blacklist.c b/certs/blacklist.c
index 97a35cf9a62c..b254c87ceb3a 100644
--- a/certs/blacklist.c
+++ b/certs/blacklist.c
@@ -109,11 +109,43 @@ static struct key_type key_type_blacklist = {
.describe = blacklist_describe,
};
+static char *get_raw_hash(const u8 *hash, size_t hash_len,
+ enum blacklist_hash_type hash_type)
+{
+ size_t type_len;
+ const char *type_prefix;
+ char *buffer, *p;
+
+ switch (hash_type) {
+ case BLACKLIST_HASH_X509_TBS:
+ type_len = sizeof(tbs_prefix) - 1;
+ type_prefix = tbs_prefix;
+ break;
+ case BLACKLIST_HASH_BINARY:
+ type_len = sizeof(bin_prefix) - 1;
+ type_prefix = bin_prefix;
+ break;
+ default:
+ WARN_ON_ONCE(1);
+ return ERR_PTR(-EINVAL);
+ }
+ buffer = kmalloc(type_len + 1 + hash_len * 2 + 1, GFP_KERNEL);
+ if (!buffer)
+ return ERR_PTR(-ENOMEM);
+ p = memcpy(buffer, type_prefix, type_len);
+ p += type_len;
+ *p++ = ':';
+ bin2hex(p, hash, hash_len);
+ p += hash_len * 2;
+ *p = '\0';
+ return buffer;
+}
+
/**
- * mark_hash_blacklisted - Add a hash to the system blacklist
+ * mark_raw_hash_blacklisted - Add a hash to the system blacklist
* @hash: The hash as a hex string with a type prefix (eg. "tbs:23aa429783")
*/
-int mark_hash_blacklisted(const char *hash)
+static int mark_raw_hash_blacklisted(const char *hash)
{
key_ref_t key;
@@ -133,29 +165,36 @@ int mark_hash_blacklisted(const char *hash)
return 0;
}
+int mark_hash_blacklisted(const u8 *hash, size_t hash_len,
+ enum blacklist_hash_type hash_type)
+{
+ const char *buffer;
+ int err;
+
+ buffer = get_raw_hash(hash, hash_len, hash_type);
+ if (IS_ERR(buffer))
+ return PTR_ERR(buffer);
+ err = mark_raw_hash_blacklisted(buffer);
+ kfree(buffer);
+ return err;
+}
+
/**
* is_hash_blacklisted - Determine if a hash is blacklisted
* @hash: The hash to be checked as a binary blob
* @hash_len: The length of the binary hash
- * @type: Type of hash
+ * @hash_type: Type of hash
*/
-int is_hash_blacklisted(const u8 *hash, size_t hash_len, const char *type)
+int is_hash_blacklisted(const u8 *hash, size_t hash_len,
+ enum blacklist_hash_type hash_type)
{
key_ref_t kref;
- size_t type_len = strlen(type);
- char *buffer, *p;
+ const char *buffer;
int ret = 0;
- buffer = kmalloc(type_len + 1 + hash_len * 2 + 1, GFP_KERNEL);
- if (!buffer)
- return -ENOMEM;
- p = memcpy(buffer, type, type_len);
- p += type_len;
- *p++ = ':';
- bin2hex(p, hash, hash_len);
- p += hash_len * 2;
- *p = 0;
-
+ buffer = get_raw_hash(hash, hash_len, hash_type);
+ if (IS_ERR(buffer))
+ return PTR_ERR(buffer);
kref = keyring_search(make_key_ref(blacklist_keyring, true),
&key_type_blacklist, buffer, false);
if (!IS_ERR(kref)) {
@@ -170,7 +209,8 @@ EXPORT_SYMBOL_GPL(is_hash_blacklisted);
int is_binary_blacklisted(const u8 *hash, size_t hash_len)
{
- if (is_hash_blacklisted(hash, hash_len, "bin") == -EKEYREJECTED)
+ if (is_hash_blacklisted(hash, hash_len, BLACKLIST_HASH_BINARY) ==
+ -EKEYREJECTED)
return -EPERM;
return 0;
@@ -243,7 +283,7 @@ static int __init blacklist_init(void)
panic("Can't allocate system blacklist keyring\n");
for (bl = blacklist_hashes; *bl; bl++)
- if (mark_hash_blacklisted(*bl) < 0)
+ if (mark_raw_hash_blacklisted(*bl) < 0)
pr_err("- blacklisting failed\n");
return 0;
}
diff --git a/crypto/asymmetric_keys/x509_public_key.c b/crypto/asymmetric_keys/x509_public_key.c
index 3d45161b271a..4b3d5166643b 100644
--- a/crypto/asymmetric_keys/x509_public_key.c
+++ b/crypto/asymmetric_keys/x509_public_key.c
@@ -81,7 +81,8 @@ int x509_get_sig_params(struct x509_certificate *cert)
if (ret < 0)
goto error_2;
- ret = is_hash_blacklisted(sig->digest, sig->digest_size, "tbs");
+ ret = is_hash_blacklisted(sig->digest, sig->digest_size,
+ BLACKLIST_HASH_X509_TBS);
if (ret == -EKEYREJECTED) {
pr_err("Cert %*phN is blacklisted\n",
sig->digest_size, sig->digest);
diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
index 6acd3cf13a18..1efb52bc494f 100644
--- a/include/keys/system_keyring.h
+++ b/include/keys/system_keyring.h
@@ -10,6 +10,13 @@
#include <linux/key.h>
+enum blacklist_hash_type {
+ /* TBSCertificate hash */
+ BLACKLIST_HASH_X509_TBS = 1,
+ /* Raw data hash */
+ BLACKLIST_HASH_BINARY = 2,
+};
+
#ifdef CONFIG_SYSTEM_TRUSTED_KEYRING
extern int restrict_link_by_builtin_trusted(struct key *keyring,
@@ -40,13 +47,14 @@ extern int restrict_link_by_builtin_and_secondary_trusted(
extern struct pkcs7_message *pkcs7;
#ifdef CONFIG_SYSTEM_BLACKLIST_KEYRING
-extern int mark_hash_blacklisted(const char *hash);
+extern int mark_hash_blacklisted(const u8 *hash, size_t hash_len,
+ enum blacklist_hash_type hash_type);
extern int is_hash_blacklisted(const u8 *hash, size_t hash_len,
- const char *type);
+ enum blacklist_hash_type hash_type);
extern int is_binary_blacklisted(const u8 *hash, size_t hash_len);
#else
static inline int is_hash_blacklisted(const u8 *hash, size_t hash_len,
- const char *type)
+ enum blacklist_hash_type hash_type)
{
return 0;
}
diff --git a/security/integrity/platform_certs/keyring_handler.c b/security/integrity/platform_certs/keyring_handler.c
index 5604bd57c990..9e4f156b356e 100644
--- a/security/integrity/platform_certs/keyring_handler.c
+++ b/security/integrity/platform_certs/keyring_handler.c
@@ -15,35 +15,13 @@ static efi_guid_t efi_cert_x509_sha256_guid __initdata =
EFI_CERT_X509_SHA256_GUID;
static efi_guid_t efi_cert_sha256_guid __initdata = EFI_CERT_SHA256_GUID;
-/*
- * Blacklist a hash.
- */
-static __init void uefi_blacklist_hash(const char *source, const void *data,
- size_t len, const char *type,
- size_t type_len)
-{
- char *hash, *p;
-
- hash = kmalloc(type_len + len * 2 + 1, GFP_KERNEL);
- if (!hash)
- return;
- p = memcpy(hash, type, type_len);
- p += type_len;
- bin2hex(p, data, len);
- p += len * 2;
- *p = 0;
-
- mark_hash_blacklisted(hash);
- kfree(hash);
-}
-
/*
* Blacklist an X509 TBS hash.
*/
static __init void uefi_blacklist_x509_tbs(const char *source,
const void *data, size_t len)
{
- uefi_blacklist_hash(source, data, len, "tbs:", 4);
+ mark_hash_blacklisted(data, len, BLACKLIST_HASH_X509_TBS);
}
/*
@@ -52,7 +30,7 @@ static __init void uefi_blacklist_x509_tbs(const char *source,
static __init void uefi_blacklist_binary(const char *source,
const void *data, size_t len)
{
- uefi_blacklist_hash(source, data, len, "bin:", 4);
+ mark_hash_blacklisted(data, len, BLACKLIST_HASH_BINARY);
}
/*
--
2.32.0
^ permalink raw reply related
* [PATCH v8 3/5] certs: Make blacklist_vet_description() more strict
From: Mickaël Salaün @ 2021-07-12 17:03 UTC (permalink / raw)
To: David Howells, David Woodhouse, Jarkko Sakkinen
Cc: Mickaël Salaün, David S . Miller, Eric Snowberg,
Herbert Xu, James Morris, Mickaël Salaün, Mimi Zohar,
Serge E . Hallyn, Tyler Hicks, keyrings, linux-crypto,
linux-integrity, linux-kernel, linux-security-module
In-Reply-To: <20210712170313.884724-1-mic@digikod.net>
From: Mickaël Salaün <mic@linux.microsoft.com>
Before exposing this new key type to user space, make sure that only
meaningful blacklisted hashes are accepted. This is also checked for
builtin blacklisted hashes, but a following commit make sure that the
user will notice (at built time) and will fix the configuration if it
already included errors.
Check that a blacklist key description starts with a valid prefix and
then a valid hexadecimal string.
Cc: David Howells <dhowells@redhat.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Eric Snowberg <eric.snowberg@oracle.com>
Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Link: https://lore.kernel.org/r/20210712170313.884724-4-mic@digikod.net
---
Changes since v5:
* Add Reviewed-by Jarkko.
Changes since v2:
* Fix typo in blacklist_vet_description() comment, spotted by Tyler
Hicks.
* Add Jarkko's Acked-by.
Changes since v1:
* Return ENOPKG (instead of EINVAL) when a hash is greater than the
maximum currently known hash (suggested by David Howells).
---
certs/blacklist.c | 46 ++++++++++++++++++++++++++++++++++++----------
1 file changed, 36 insertions(+), 10 deletions(-)
diff --git a/certs/blacklist.c b/certs/blacklist.c
index c9a435b15af4..97a35cf9a62c 100644
--- a/certs/blacklist.c
+++ b/certs/blacklist.c
@@ -19,6 +19,16 @@
#include "blacklist.h"
#include "common.h"
+/*
+ * According to crypto/asymmetric_keys/x509_cert_parser.c:x509_note_pkey_algo(),
+ * the size of the currently longest supported hash algorithm is 512 bits,
+ * which translates into 128 hex characters.
+ */
+#define MAX_HASH_LEN 128
+
+static const char tbs_prefix[] = "tbs";
+static const char bin_prefix[] = "bin";
+
static struct key *blacklist_keyring;
#ifdef CONFIG_SYSTEM_REVOCATION_LIST
@@ -32,24 +42,40 @@ extern __initconst const unsigned long revocation_certificate_list_size;
*/
static int blacklist_vet_description(const char *desc)
{
- int n = 0;
-
- if (*desc == ':')
- return -EINVAL;
- for (; *desc; desc++)
- if (*desc == ':')
- goto found_colon;
+ int i, prefix_len, tbs_step = 0, bin_step = 0;
+
+ /* The following algorithm only works if prefix lengths match. */
+ BUILD_BUG_ON(sizeof(tbs_prefix) != sizeof(bin_prefix));
+ prefix_len = sizeof(tbs_prefix) - 1;
+ for (i = 0; *desc; desc++, i++) {
+ if (*desc == ':') {
+ if (tbs_step == prefix_len)
+ goto found_colon;
+ if (bin_step == prefix_len)
+ goto found_colon;
+ return -EINVAL;
+ }
+ if (i >= prefix_len)
+ return -EINVAL;
+ if (*desc == tbs_prefix[i])
+ tbs_step++;
+ if (*desc == bin_prefix[i])
+ bin_step++;
+ }
return -EINVAL;
found_colon:
desc++;
- for (; *desc; desc++) {
+ for (i = 0; *desc && i < MAX_HASH_LEN; desc++, i++) {
if (!isxdigit(*desc) || isupper(*desc))
return -EINVAL;
- n++;
}
+ if (*desc)
+ /* The hash is greater than MAX_HASH_LEN. */
+ return -ENOPKG;
- if (n == 0 || n & 1)
+ /* Checks for an even number of hexadecimal characters. */
+ if (i == 0 || i & 1)
return -EINVAL;
return 0;
}
--
2.32.0
^ permalink raw reply related
* [PATCH v8 1/5] tools/certs: Add print-cert-tbs-hash.sh
From: Mickaël Salaün @ 2021-07-12 17:03 UTC (permalink / raw)
To: David Howells, David Woodhouse, Jarkko Sakkinen
Cc: Mickaël Salaün, David S . Miller, Eric Snowberg,
Herbert Xu, James Morris, Mickaël Salaün, Mimi Zohar,
Serge E . Hallyn, Tyler Hicks, keyrings, linux-crypto,
linux-integrity, linux-kernel, linux-security-module
In-Reply-To: <20210712170313.884724-1-mic@digikod.net>
From: Mickaël Salaün <mic@linux.microsoft.com>
Add a new helper print-cert-tbs-hash.sh to generate a TBSCertificate
hash from a given certificate. This is useful to generate a blacklist
key description used to forbid loading a specific certificate in a
keyring, or to invalidate a certificate provided by a PKCS#7 file.
This kind of hash formatting is required to populate the file pointed
out by CONFIG_SYSTEM_BLACKLIST_HASH_LIST, but only the kernel code was
available to understand how to effectively create such hash.
Cc: David Howells <dhowells@redhat.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Eric Snowberg <eric.snowberg@oracle.com>
Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Link: https://lore.kernel.org/r/20210712170313.884724-2-mic@digikod.net
---
Changes since v5:
* Add Reviewed-by Jarkko.
Changes since v3:
* Explain in the commit message that this kind of formating is not new
but it wasn't documented.
Changes since v1:
* Fix typo.
* Use "if" block instead of "||" .
---
MAINTAINERS | 1 +
tools/certs/print-cert-tbs-hash.sh | 91 ++++++++++++++++++++++++++++++
2 files changed, 92 insertions(+)
create mode 100755 tools/certs/print-cert-tbs-hash.sh
diff --git a/MAINTAINERS b/MAINTAINERS
index a61f4f3b78a9..0b3be78d27ef 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4301,6 +4301,7 @@ F: Documentation/admin-guide/module-signing.rst
F: certs/
F: scripts/extract-cert.c
F: scripts/sign-file.c
+F: tools/certs/
CFAG12864B LCD DRIVER
M: Miguel Ojeda <ojeda@kernel.org>
diff --git a/tools/certs/print-cert-tbs-hash.sh b/tools/certs/print-cert-tbs-hash.sh
new file mode 100755
index 000000000000..c93df5387ec9
--- /dev/null
+++ b/tools/certs/print-cert-tbs-hash.sh
@@ -0,0 +1,91 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+#
+# Copyright © 2020, Microsoft Corporation. All rights reserved.
+#
+# Author: Mickaël Salaün <mic@linux.microsoft.com>
+#
+# Compute and print the To Be Signed (TBS) hash of a certificate. This is used
+# as description of keys in the blacklist keyring to identify certificates.
+# This output should be redirected, without newline, in a file (hash0.txt) and
+# signed to create a PKCS#7 file (hash0.p7s). Both of these files can then be
+# loaded in the kernel with.
+#
+# Exemple on a workstation:
+# ./print-cert-tbs-hash.sh certificate-to-invalidate.pem > hash0.txt
+# openssl smime -sign -in hash0.txt -inkey builtin-private-key.pem \
+# -signer builtin-certificate.pem -certfile certificate-chain.pem \
+# -noattr -binary -outform DER -out hash0.p7s
+#
+# Exemple on a managed system:
+# keyctl padd blacklist "$(< hash0.txt)" %:.blacklist < hash0.p7s
+
+set -u -e -o pipefail
+
+CERT="${1:-}"
+BASENAME="$(basename -- "${BASH_SOURCE[0]}")"
+
+if [ $# -ne 1 ] || [ ! -f "${CERT}" ]; then
+ echo "usage: ${BASENAME} <certificate>" >&2
+ exit 1
+fi
+
+# Checks that it is indeed a certificate (PEM or DER encoded) and exclude the
+# optional PEM text header.
+if ! PEM="$(openssl x509 -inform DER -in "${CERT}" 2>/dev/null || openssl x509 -in "${CERT}")"; then
+ echo "ERROR: Failed to parse certificate" >&2
+ exit 1
+fi
+
+# TBSCertificate starts at the second entry.
+# Cf. https://tools.ietf.org/html/rfc3280#section-4.1
+#
+# Exemple of first lines printed by openssl asn1parse:
+# 0:d=0 hl=4 l= 763 cons: SEQUENCE
+# 4:d=1 hl=4 l= 483 cons: SEQUENCE
+# 8:d=2 hl=2 l= 3 cons: cont [ 0 ]
+# 10:d=3 hl=2 l= 1 prim: INTEGER :02
+# 13:d=2 hl=2 l= 20 prim: INTEGER :3CEB2CB8818D968AC00EEFE195F0DF9665328B7B
+# 35:d=2 hl=2 l= 13 cons: SEQUENCE
+# 37:d=3 hl=2 l= 9 prim: OBJECT :sha256WithRSAEncryption
+RANGE_AND_DIGEST_RE='
+2s/^\s*\([0-9]\+\):d=\s*[0-9]\+\s\+hl=\s*[0-9]\+\s\+l=\s*\([0-9]\+\)\s\+cons:\s*SEQUENCE\s*$/\1 \2/p;
+7s/^\s*[0-9]\+:d=\s*[0-9]\+\s\+hl=\s*[0-9]\+\s\+l=\s*[0-9]\+\s\+prim:\s*OBJECT\s*:\(.*\)$/\1/p;
+'
+
+RANGE_AND_DIGEST=($(echo "${PEM}" | \
+ openssl asn1parse -in - | \
+ sed -n -e "${RANGE_AND_DIGEST_RE}"))
+
+if [ "${#RANGE_AND_DIGEST[@]}" != 3 ]; then
+ echo "ERROR: Failed to parse TBSCertificate." >&2
+ exit 1
+fi
+
+OFFSET="${RANGE_AND_DIGEST[0]}"
+END="$(( OFFSET + RANGE_AND_DIGEST[1] ))"
+DIGEST="${RANGE_AND_DIGEST[2]}"
+
+# The signature hash algorithm is used by Linux to blacklist certificates.
+# Cf. crypto/asymmetric_keys/x509_cert_parser.c:x509_note_pkey_algo()
+DIGEST_MATCH=""
+while read -r DIGEST_ITEM; do
+ if [ -z "${DIGEST_ITEM}" ]; then
+ break
+ fi
+ if echo "${DIGEST}" | grep -qiF "${DIGEST_ITEM}"; then
+ DIGEST_MATCH="${DIGEST_ITEM}"
+ break
+ fi
+done < <(openssl list -digest-commands | tr ' ' '\n' | sort -ur)
+
+if [ -z "${DIGEST_MATCH}" ]; then
+ echo "ERROR: Unknown digest algorithm: ${DIGEST}" >&2
+ exit 1
+fi
+
+echo "${PEM}" | \
+ openssl x509 -in - -outform DER | \
+ dd "bs=1" "skip=${OFFSET}" "count=${END}" "status=none" | \
+ openssl dgst "-${DIGEST_MATCH}" - | \
+ awk '{printf "tbs:" $2}'
--
2.32.0
^ permalink raw reply related
* [PATCH v8 2/5] certs: Check that builtin blacklist hashes are valid
From: Mickaël Salaün @ 2021-07-12 17:03 UTC (permalink / raw)
To: David Howells, David Woodhouse, Jarkko Sakkinen
Cc: Mickaël Salaün, David S . Miller, Eric Snowberg,
Herbert Xu, James Morris, Mickaël Salaün, Mimi Zohar,
Serge E . Hallyn, Tyler Hicks, keyrings, linux-crypto,
linux-integrity, linux-kernel, linux-security-module
In-Reply-To: <20210712170313.884724-1-mic@digikod.net>
From: Mickaël Salaün <mic@linux.microsoft.com>
Add and use a check-blacklist-hashes.awk script to make sure that the
builtin blacklist hashes set with CONFIG_SYSTEM_BLACKLIST_HASH_LIST will
effectively be taken into account as blacklisted hashes. This is useful
to debug invalid hash formats, and it make sure that previous hashes
which could have been loaded in the kernel, but silently ignored, are
now noticed and deal with by the user at kernel build time.
This also prevent stricter blacklist key description checking (provided
by following commits) to failed for builtin hashes.
Update CONFIG_SYSTEM_BLACKLIST_HASH_LIST help to explain the content of
a hash string and how to generate certificate ones.
Cc: David Howells <dhowells@redhat.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Eric Snowberg <eric.snowberg@oracle.com>
Cc: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com>
Link: https://lore.kernel.org/r/20210712170313.884724-3-mic@digikod.net
---
Changes since v7:
* Rebase and fix trivial .gitignore conflict.
Changes since v5:
* Rebase on keys-next and fix conflict as previously done by David
Howells.
* Enable to use a file path relative to the kernel source directory.
This align with the handling of CONFIG_SYSTEM_TRUSTED_KEYS,
CONFIG_MODULE_SIG_KEY and CONFIG_SYSTEM_REVOCATION_KEYS.
Changes since v3:
* Improve commit description.
* Update CONFIG_SYSTEM_BLACKLIST_HASH_LIST help.
* Remove Acked-by Jarkko Sakkinen because of the above changes.
Changes since v2:
* Add Jarkko's Acked-by.
Changes since v1:
* Prefix script path with $(scrtree)/ (suggested by David Howells).
* Fix hexadecimal number check.
---
MAINTAINERS | 1 +
certs/.gitignore | 1 +
certs/Kconfig | 7 ++++--
certs/Makefile | 17 +++++++++++++-
scripts/check-blacklist-hashes.awk | 37 ++++++++++++++++++++++++++++++
5 files changed, 60 insertions(+), 3 deletions(-)
create mode 100755 scripts/check-blacklist-hashes.awk
diff --git a/MAINTAINERS b/MAINTAINERS
index 0b3be78d27ef..04b8fb5dcdac 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4299,6 +4299,7 @@ L: keyrings@vger.kernel.org
S: Maintained
F: Documentation/admin-guide/module-signing.rst
F: certs/
+F: scripts/check-blacklist-hashes.awk
F: scripts/extract-cert.c
F: scripts/sign-file.c
F: tools/certs/
diff --git a/certs/.gitignore b/certs/.gitignore
index 8c3763f80be3..01de9442e4e2 100644
--- a/certs/.gitignore
+++ b/certs/.gitignore
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
+/blacklist_hashes_checked
/x509_certificate_list
/x509_revocation_list
diff --git a/certs/Kconfig b/certs/Kconfig
index f4e61116f94e..0fbe184ceca5 100644
--- a/certs/Kconfig
+++ b/certs/Kconfig
@@ -80,8 +80,11 @@ config SYSTEM_BLACKLIST_HASH_LIST
help
If set, this option should be the filename of a list of hashes in the
form "<hash>", "<hash>", ... . This will be included into a C
- wrapper to incorporate the list into the kernel. Each <hash> should
- be a string of hex digits.
+ wrapper to incorporate the list into the kernel. Each <hash> must be a
+ string starting with a prefix ("tbs" or "bin"), then a colon (":"), and
+ finally an even number of hexadecimal lowercase characters (up to 128).
+ Certificate hashes can be generated with
+ tools/certs/print-cert-tbs-hash.sh .
config SYSTEM_REVOCATION_LIST
bool "Provide system-wide ring of revocation certificates"
diff --git a/certs/Makefile b/certs/Makefile
index 359239a0ee9e..e43c1a8032de 100644
--- a/certs/Makefile
+++ b/certs/Makefile
@@ -7,7 +7,22 @@ obj-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += system_keyring.o system_certificates.o c
obj-$(CONFIG_SYSTEM_BLACKLIST_KEYRING) += blacklist.o common.o
obj-$(CONFIG_SYSTEM_REVOCATION_LIST) += revocation_certificates.o
ifneq ($(CONFIG_SYSTEM_BLACKLIST_HASH_LIST),"")
+
+quiet_cmd_check_blacklist_hashes = CHECK $(patsubst "%",%,$(2))
+ cmd_check_blacklist_hashes = $(AWK) -f $(srctree)/scripts/check-blacklist-hashes.awk $(2); touch $@
+
+$(eval $(call config_filename,SYSTEM_BLACKLIST_HASH_LIST))
+
+$(obj)/blacklist_hashes.o: $(obj)/blacklist_hashes_checked
+
+CFLAGS_blacklist_hashes.o += -I$(srctree)
+
+targets += blacklist_hashes_checked
+$(obj)/blacklist_hashes_checked: $(SYSTEM_BLACKLIST_HASH_LIST_SRCPREFIX)$(SYSTEM_BLACKLIST_HASH_LIST_FILENAME) scripts/check-blacklist-hashes.awk FORCE
+ $(call if_changed,check_blacklist_hashes,$(SYSTEM_BLACKLIST_HASH_LIST_SRCPREFIX)$(CONFIG_SYSTEM_BLACKLIST_HASH_LIST))
+
obj-$(CONFIG_SYSTEM_BLACKLIST_KEYRING) += blacklist_hashes.o
+
else
obj-$(CONFIG_SYSTEM_BLACKLIST_KEYRING) += blacklist_nohashes.o
endif
@@ -30,7 +45,7 @@ $(obj)/x509_certificate_list: scripts/extract-cert $(SYSTEM_TRUSTED_KEYS_SRCPREF
$(call if_changed,extract_certs,$(SYSTEM_TRUSTED_KEYS_SRCPREFIX)$(CONFIG_SYSTEM_TRUSTED_KEYS))
endif # CONFIG_SYSTEM_TRUSTED_KEYRING
-clean-files := x509_certificate_list .x509.list x509_revocation_list
+clean-files := x509_certificate_list .x509.list x509_revocation_list blacklist_hashes_checked
ifeq ($(CONFIG_MODULE_SIG),y)
SIGN_KEY = y
diff --git a/scripts/check-blacklist-hashes.awk b/scripts/check-blacklist-hashes.awk
new file mode 100755
index 000000000000..107c1d3204d4
--- /dev/null
+++ b/scripts/check-blacklist-hashes.awk
@@ -0,0 +1,37 @@
+#!/usr/bin/awk -f
+# SPDX-License-Identifier: GPL-2.0
+#
+# Copyright © 2020, Microsoft Corporation. All rights reserved.
+#
+# Author: Mickaël Salaün <mic@linux.microsoft.com>
+#
+# Check that a CONFIG_SYSTEM_BLACKLIST_HASH_LIST file contains a valid array of
+# hash strings. Such string must start with a prefix ("tbs" or "bin"), then a
+# colon (":"), and finally an even number of hexadecimal lowercase characters
+# (up to 128).
+
+BEGIN {
+ RS = ","
+}
+{
+ if (!match($0, "^[ \t\n\r]*\"([^\"]*)\"[ \t\n\r]*$", part1)) {
+ print "Not a string (item " NR "):", $0;
+ exit 1;
+ }
+ if (!match(part1[1], "^(tbs|bin):(.*)$", part2)) {
+ print "Unknown prefix (item " NR "):", part1[1];
+ exit 1;
+ }
+ if (!match(part2[2], "^([0-9a-f]+)$", part3)) {
+ print "Not a lowercase hexadecimal string (item " NR "):", part2[2];
+ exit 1;
+ }
+ if (length(part3[1]) > 128) {
+ print "Hash string too long (item " NR "):", part3[1];
+ exit 1;
+ }
+ if (length(part3[1]) % 2 == 1) {
+ print "Not an even number of hexadecimal characters (item " NR "):", part3[1];
+ exit 1;
+ }
+}
--
2.32.0
^ permalink raw reply related
* [PATCH v8 0/5] Enable root to update the blacklist keyring
From: Mickaël Salaün @ 2021-07-12 17:03 UTC (permalink / raw)
To: David Howells, David Woodhouse, Jarkko Sakkinen
Cc: Mickaël Salaün, David S . Miller, Eric Snowberg,
Herbert Xu, James Morris, Mickaël Salaün, Mimi Zohar,
Serge E . Hallyn, Tyler Hicks, keyrings, linux-crypto,
linux-integrity, linux-kernel, linux-security-module
Hi,
This new patch series is a rebase on v5.14-rc1 . David or Jarkko, if
it's still OK with you, could you please push this to linux-next?
I successfully tested this patch series with the 211 entries from
https://uefi.org/sites/default/files/resources/dbxupdate_x64.bin
The goal of these patches is to add a new configuration option to enable the
root user to load signed keys in the blacklist keyring. This keyring is useful
to "untrust" certificates or files. Enabling to safely update this keyring
without recompiling the kernel makes it more usable.
Previous patch series:
https://lore.kernel.org/lkml/20210312171232.2681989-1-mic@digikod.net/
Regards,
Mickaël Salaün (5):
tools/certs: Add print-cert-tbs-hash.sh
certs: Check that builtin blacklist hashes are valid
certs: Make blacklist_vet_description() more strict
certs: Factor out the blacklist hash creation
certs: Allow root user to append signed hashes to the blacklist
keyring
MAINTAINERS | 2 +
certs/.gitignore | 1 +
certs/Kconfig | 17 +-
certs/Makefile | 17 +-
certs/blacklist.c | 218 ++++++++++++++----
crypto/asymmetric_keys/x509_public_key.c | 3 +-
include/keys/system_keyring.h | 14 +-
scripts/check-blacklist-hashes.awk | 37 +++
.../platform_certs/keyring_handler.c | 26 +--
tools/certs/print-cert-tbs-hash.sh | 91 ++++++++
10 files changed, 346 insertions(+), 80 deletions(-)
create mode 100755 scripts/check-blacklist-hashes.awk
create mode 100755 tools/certs/print-cert-tbs-hash.sh
base-commit: e73f0f0ee7541171d89f2e2491130c7771ba58d3
--
2.32.0
^ permalink raw reply
* [PATCH] tpm: ibmvtpm: Avoid error message when process gets signal while waiting
From: Stefan Berger @ 2021-07-12 16:25 UTC (permalink / raw)
To: peterhuewe, jarkko
Cc: jgg, linux-integrity, linux-security-module, linux-kernel,
Stefan Berger, Nayna Jain, George Wilson, Nageswara R Sastry
From: Stefan Berger <stefanb@linux.ibm.com>
When rngd is run as root then lots of these types of message will appear
in the kernel log if the TPM has been configure to provide random bytes:
[ 7406.275163] tpm tpm0: tpm_transmit: tpm_recv: error -4
The issue is caused by the following call that is interrupted while
waiting for the TPM's response.
sig = wait_event_interruptible(ibmvtpm->wq,
!ibmvtpm->tpm_processing_cmd);
The solution is to use wait_event() instead.
To recreat the issue start rngd like this:
sudo rngd -r /dev/hwrng -t
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1981473
Fixes: 6674ff145eef ("tpm_ibmvtpm: properly handle interrupted packet receptions")
Cc: Nayna Jain <nayna@linux.ibm.com>
Cc: George Wilson <gcwilson@linux.ibm.com>
Reported-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
---
drivers/char/tpm/tpm_ibmvtpm.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index 903604769de9..99b0442a5fdf 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -106,16 +106,13 @@ static int tpm_ibmvtpm_recv(struct tpm_chip *chip, u8 *buf, size_t count)
{
struct ibmvtpm_dev *ibmvtpm = dev_get_drvdata(&chip->dev);
u16 len;
- int sig;
if (!ibmvtpm->rtce_buf) {
dev_err(ibmvtpm->dev, "ibmvtpm device is not ready\n");
return 0;
}
- sig = wait_event_interruptible(ibmvtpm->wq, !ibmvtpm->tpm_processing_cmd);
- if (sig)
- return -EINTR;
+ wait_event(ibmvtpm->wq, !ibmvtpm->tpm_processing_cmd);
len = ibmvtpm->res_len;
@@ -206,7 +203,7 @@ static int tpm_ibmvtpm_send(struct tpm_chip *chip, u8 *buf, size_t count)
{
struct ibmvtpm_dev *ibmvtpm = dev_get_drvdata(&chip->dev);
bool retry = true;
- int rc, sig;
+ int rc;
if (!ibmvtpm->rtce_buf) {
dev_err(ibmvtpm->dev, "ibmvtpm device is not ready\n");
@@ -224,9 +221,7 @@ static int tpm_ibmvtpm_send(struct tpm_chip *chip, u8 *buf, size_t count)
dev_info(ibmvtpm->dev,
"Need to wait for TPM to finish\n");
/* wait for previous command to finish */
- sig = wait_event_interruptible(ibmvtpm->wq, !ibmvtpm->tpm_processing_cmd);
- if (sig)
- return -EINTR;
+ wait_event(ibmvtpm->wq, !ibmvtpm->tpm_processing_cmd);
}
spin_lock(&ibmvtpm->rtce_lock);
@@ -551,7 +546,7 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq *crq,
/* len of the data in rtce buffer */
ibmvtpm->res_len = be16_to_cpu(crq->len);
ibmvtpm->tpm_processing_cmd = false;
- wake_up_interruptible(&ibmvtpm->wq);
+ wake_up(&ibmvtpm->wq);
return;
default:
return;
--
2.31.1
^ permalink raw reply related
* [PATCH v2 4/4] landlock_restrict_self.2: Document new syscall
From: Mickaël Salaün @ 2021-07-12 15:57 UTC (permalink / raw)
To: Alejandro Colomar, Michael Kerrisk
Cc: Mickaël Salaün, Jann Horn, Jonathan Corbet, Kees Cook,
Randy Dunlap, Vincent Dagonneau, landlock, linux-kernel,
linux-man, linux-security-module, Mickaël Salaün
In-Reply-To: <20210712155745.831580-1-mic@digikod.net>
From: Mickaël Salaün <mic@linux.microsoft.com>
This is an adaptation of
https://www.kernel.org/doc/html/v5.13/userspace-api/landlock.html
Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com>
Link: https://lore.kernel.org/r/20210712155745.831580-5-mic@digikod.net
---
Changes since v1:
* Replace all ".I" with ".IR", except when used for titles.
* Append punctuation to ".IR" and ".BR" when it makes sense (requested
by Alejandro Colomar).
* Cut lines according to the semantic newline rules (requested by
Alejandro Colomar).
* Remove roman style from ".TP" section titles (requested by Alejandro
Colomar).
* Add comma after "i.e." and "e.g.".
* Add a "CONFORMING TO" section.
* Replace "(2)" with "()" for the described syscall name.
---
man2/landlock_restrict_self.2 | 130 ++++++++++++++++++++++++++++++++++
1 file changed, 130 insertions(+)
create mode 100644 man2/landlock_restrict_self.2
diff --git a/man2/landlock_restrict_self.2 b/man2/landlock_restrict_self.2
new file mode 100644
index 000000000000..41b21278905a
--- /dev/null
+++ b/man2/landlock_restrict_self.2
@@ -0,0 +1,130 @@
+.\" Copyright © 2017-2020 Mickaël Salaün <mic@digikod.net>
+.\" Copyright © 2019-2020 ANSSI
+.\" Copyright © 2021 Microsoft Corporation
+.\"
+.\" %%%LICENSE_START(VERBATIM)
+.\" Permission is granted to make and distribute verbatim copies of this
+.\" manual provided the copyright notice and this permission notice are
+.\" preserved on all copies.
+.\"
+.\" Permission is granted to copy and distribute modified versions of this
+.\" manual under the conditions for verbatim copying, provided that the
+.\" entire resulting derived work is distributed under the terms of a
+.\" permission notice identical to this one.
+.\"
+.\" Since the Linux kernel and libraries are constantly changing, this
+.\" manual page may be incorrect or out-of-date. The author(s) assume no
+.\" responsibility for errors or omissions, or for damages resulting from
+.\" the use of the information contained herein. The author(s) may not
+.\" have taken the same level of care in the production of this manual,
+.\" which is licensed free of charge, as they might when working
+.\" professionally.
+.\"
+.\" Formatted or processed versions of this manual, if unaccompanied by
+.\" the source, must acknowledge the copyright and authors of this work.
+.\" %%%LICENSE_END
+.\"
+.TH LANDLOCK_RESTRICT_SELF 2 2021-06-27 Linux "Linux Programmer's Manual"
+.SH NAME
+landlock_restrict_self \- enforce a Landlock ruleset
+.SH SYNOPSIS
+.nf
+.BR "#include <linux/landlock.h>" " /* Definition of " LANDLOCK_* " constants */"
+.BR "#include <sys/syscall.h>" " /* Definition of " SYS_* " constants */"
+.PP
+.BI "int syscall(SYS_landlock_restrict_self, int " ruleset_fd ,
+.BI " __u32 " flags );
+.SH DESCRIPTION
+Once a Landlock ruleset is populated with the desired rules, the
+.BR landlock_restrict_self ()
+system call enables enforcing this ruleset on the calling thread.
+See
+.BR landlock (7)
+for a global overview.
+.PP
+A thread can be restricted with multiple rulesets that are then composed
+together to form the thread's Landlock domain.
+This can be seen as a stack of rulesets but it is implemented in a more
+efficient way.
+A domain can only be updated in such a way that the constraints of each
+past and future composed rulesets will restrict the thread and its future
+children for their entire life.
+It is then possible to gradually enforce tailored access control policies
+with multiple independant rulesets coming from different sources
+(e.g., init system configuration, user session policy,
+built-in application policy).
+However, most applications should only need one call to
+.BR landlock_restrict_self ()
+and they should avoid arbitrary numbers of such calls because of the
+composed rulesets limit.
+Instead, developers are encouraged to build a tailored ruleset thanks to
+multiple calls to
+.BR landlock_add_rule (2).
+.PP
+In order to enforce a ruleset, either the caller must have the
+.BR CAP_SYS_ADMIN
+capability in its user namespace, or the thread must already have the
+.IR no_new_privs
+bit set.
+As for
+.BR seccomp (2),
+this avoids scenarios where unprivileged processes can affect the behavior
+of privileged children (e.g., because of set-user-ID binaries).
+If that bit was not already set by an ancestor of this thread,
+the thread must make the following call:
+.IP
+.EX
+prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
+.EE
+.PP
+.IR ruleset_fd
+is a Landlock ruleset file descriptor obtained with
+.BR landlock_create_ruleset (2)
+and fully populated with a set of calls to
+.BR landlock_add_rule (2).
+.PP
+.IR flags
+must be 0.
+.SH RETURN VALUE
+On success,
+.BR landlock_restrict_self ()
+returns 0.
+.SH ERRORS
+.BR landlock_restrict_self ()
+can failed for the following reasons:
+.TP
+.B EOPNOTSUPP
+Landlock is supported by the kernel but disabled at boot time.
+.TP
+.B EINVAL
+.IR flags
+is not 0.
+.TP
+.B EBADF
+.IR ruleset_fd
+is not a file descriptor for the current thread.
+.TP
+.B EBADFD
+.IR ruleset_fd
+is not a ruleset file descriptor.
+.TP
+.B EPERM
+.IR ruleset_fd
+has no read access to the underlying ruleset,
+or the calling thread is not running with
+.IR no_new_privs ,
+or it doesn't have the
+.BR CAP_SYS_ADMIN
+in its user namespace.
+.TP
+.B E2BIG
+The maximum number of composed rulesets is reached for the calling thread.
+This limit is currently 64.
+.SH VERSIONS
+Landlock was added in Linux 5.13.
+.SH CONFORMING TO
+This system call is Linux-specific.
+.SH SEE ALSO
+.BR landlock (7),
+.BR landlock_create_ruleset (2),
+.BR landlock_add_rule (2)
--
2.32.0
^ permalink raw reply related
* [PATCH v2 3/4] landlock_add_rule.2: Document new syscall
From: Mickaël Salaün @ 2021-07-12 15:57 UTC (permalink / raw)
To: Alejandro Colomar, Michael Kerrisk
Cc: Mickaël Salaün, Jann Horn, Jonathan Corbet, Kees Cook,
Randy Dunlap, Vincent Dagonneau, landlock, linux-kernel,
linux-man, linux-security-module, Mickaël Salaün
In-Reply-To: <20210712155745.831580-1-mic@digikod.net>
From: Mickaël Salaün <mic@linux.microsoft.com>
This is an adaptation of
https://www.kernel.org/doc/html/v5.13/userspace-api/landlock.html
Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com>
Link: https://lore.kernel.org/r/20210712155745.831580-4-mic@digikod.net
---
Changes since v1:
* Replace all ".I" with ".IR", except when used for titles.
* Append punctuation to ".IR" and ".BR" when it makes sense (requested
by Alejandro Colomar).
* Cut lines according to the semantic newline rules (requested by
Alejandro Colomar).
* Remove roman style from ".TP" section titles (requested by Alejandro
Colomar).
* Add comma after "i.e." and "e.g.".
* Add a "CONFORMING TO" section.
* Replace "(2)" with "()" for the described syscall name.
---
man2/landlock_add_rule.2 | 139 +++++++++++++++++++++++++++++++++++++++
1 file changed, 139 insertions(+)
create mode 100644 man2/landlock_add_rule.2
diff --git a/man2/landlock_add_rule.2 b/man2/landlock_add_rule.2
new file mode 100644
index 000000000000..06ff55821222
--- /dev/null
+++ b/man2/landlock_add_rule.2
@@ -0,0 +1,139 @@
+.\" Copyright © 2017-2020 Mickaël Salaün <mic@digikod.net>
+.\" Copyright © 2019-2020 ANSSI
+.\" Copyright © 2021 Microsoft Corporation
+.\"
+.\" %%%LICENSE_START(VERBATIM)
+.\" Permission is granted to make and distribute verbatim copies of this
+.\" manual provided the copyright notice and this permission notice are
+.\" preserved on all copies.
+.\"
+.\" Permission is granted to copy and distribute modified versions of this
+.\" manual under the conditions for verbatim copying, provided that the
+.\" entire resulting derived work is distributed under the terms of a
+.\" permission notice identical to this one.
+.\"
+.\" Since the Linux kernel and libraries are constantly changing, this
+.\" manual page may be incorrect or out-of-date. The author(s) assume no
+.\" responsibility for errors or omissions, or for damages resulting from
+.\" the use of the information contained herein. The author(s) may not
+.\" have taken the same level of care in the production of this manual,
+.\" which is licensed free of charge, as they might when working
+.\" professionally.
+.\"
+.\" Formatted or processed versions of this manual, if unaccompanied by
+.\" the source, must acknowledge the copyright and authors of this work.
+.\" %%%LICENSE_END
+.\"
+.TH LANDLOCK_ADD_RULE 2 2021-06-27 Linux "Linux Programmer's Manual"
+.SH NAME
+landlock_add_rule \- add a new Landlock rule to a ruleset
+.SH SYNOPSIS
+.nf
+.BR "#include <linux/landlock.h>" " /* Definition of " LANDLOCK_* " constants */"
+.BR "#include <sys/syscall.h>" " /* Definition of " SYS_* " constants */"
+.PP
+.BI "int syscall(SYS_landlock_add_rule, int " ruleset_fd ,
+.BI " enum landlock_rule_type " rule_type ,
+.BI " const void * " rule_attr ", __u32 " flags );
+.SH DESCRIPTION
+A Landlock rule describes an action on an object.
+An object is currently a file hierarchy, and the related filesystem actions
+are defined with a set of access rights.
+This
+.BR landlock_add_rule ()
+system call enables adding a new Landlock rule to an existing ruleset
+created with
+.BR landlock_create_ruleset (2).
+See
+.BR landlock (7)
+for a global overview.
+.PP
+.IR ruleset_fd
+is a Landlock ruleset file descriptor obtained with
+.BR landlock_create_ruleset (2).
+.PP
+.IR rule_type
+identifies the structure type pointed to by
+.IR rule_attr .
+Currently, Linux supports the following
+.IR rule_type
+value:
+.TP
+.B LANDLOCK_RULE_PATH_BENEATH
+This defines the object type as a file hierarchy.
+In this case,
+.IR rule_attr
+points to the following structure:
+.IP
+.in +4n
+.EX
+struct landlock_path_beneath_attr {
+ __u64 allowed_access;
+ __s32 parent_fd;
+} __attribute__((packed));
+.EE
+.in
+.IP
+.IR allowed_access
+contains a bitmask of allowed filesystem actions for this file hierarchy
+(see
+.BR "Filesystem actions"
+in
+.BR landlock (7)).
+.IP
+.IR parent_fd
+is an opened file descriptor, preferably with the
+.IR O_PATH flag,
+which identifies the parent directory of the file hierarchy or a just file.
+.PP
+.IR flags
+must be 0.
+.SH RETURN VALUE
+On success,
+.BR landlock_add_rule ()
+returns 0.
+.SH ERRORS
+.BR landlock_add_rule ()
+can failed for the following reasons:
+.TP
+.B EOPNOTSUPP
+Landlock is supported by the kernel but disabled at boot time.
+.TP
+.B EINVAL
+.IR flags
+is not 0, or the rule accesses are inconsistent (i.e.,
+.IR rule_attr->allowed_access
+is not a subset of the ruleset handled accesses).
+.TP
+.B ENOMSG
+Empty accesses (i.e.,
+.IR rule_attr->allowed_access
+is 0).
+.TP
+.B EBADF
+.IR ruleset_fd
+is not a file descriptor for the current thread, or a member of
+.IR rule_attr
+is not a file descriptor as expected.
+.TP
+.B EBADFD
+.IR ruleset_fd
+is not a ruleset file descriptor, or a member of
+.IR rule_attr
+is not the expected file descriptor type.
+.TP
+.B EPERM
+.IR ruleset_fd
+has no write access to the underlying ruleset.
+.TP
+.B EFAULT
+.IR rule_attr
+was not a valid address.
+.SH VERSIONS
+Landlock was added in Linux 5.13.
+.SH CONFORMING TO
+This system call is Linux-specific.
+.SH SEE ALSO
+.BR landlock (7),
+.BR landlock_create_ruleset (2),
+.BR landlock_restrict_self (2)
--
2.32.0
^ permalink raw reply related
* [PATCH v2 1/4] landlock.7: Add a new page to introduce Landlock
From: Mickaël Salaün @ 2021-07-12 15:57 UTC (permalink / raw)
To: Alejandro Colomar, Michael Kerrisk
Cc: Mickaël Salaün, Jann Horn, Jonathan Corbet, Kees Cook,
Randy Dunlap, Vincent Dagonneau, landlock, linux-kernel,
linux-man, linux-security-module, Mickaël Salaün
In-Reply-To: <20210712155745.831580-1-mic@digikod.net>
From: Mickaël Salaün <mic@linux.microsoft.com>
From the user point of view, Landlock is a set of system calls enabling
to build and enforce a set of access-control rules. A ruleset can be
created with landlock_create_ruleset(2), populated with
landlock_add_rule(2) and enforced with landlock_restrict_self(2). This
man page gives an overview of the whole mechanism. Details of these
system calls are documented in their respective man pages.
This is an adaptation of
https://www.kernel.org/doc/html/v5.13/userspace-api/landlock.html
Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com>
Link: https://lore.kernel.org/r/20210712155745.831580-2-mic@digikod.net
---
Changes since v1:
* Replace all ".I" with ".IR", except when used for titles.
* Append punctuation to ".IR" and ".BR" when it makes sense (requested
by Alejandro Colomar).
* Cut lines according to the semantic newline rules (requested by
Alejandro Colomar).
* Remove roman style from ".TP" section titles (requested by Alejandro
Colomar).
* Add comma after "i.e." and "e.g.".
* Move the example in a new EXAMPLES section.
* Improve title.
* Explain the LSM acronym at first use.
---
man7/landlock.7 | 356 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 356 insertions(+)
create mode 100644 man7/landlock.7
diff --git a/man7/landlock.7 b/man7/landlock.7
new file mode 100644
index 000000000000..c89f5b1cabb6
--- /dev/null
+++ b/man7/landlock.7
@@ -0,0 +1,356 @@
+.\" Copyright © 2017-2020 Mickaël Salaün <mic@digikod.net>
+.\" Copyright © 2019-2020 ANSSI
+.\" Copyright © 2021 Microsoft Corporation
+.\"
+.\" %%%LICENSE_START(VERBATIM)
+.\" Permission is granted to make and distribute verbatim copies of this
+.\" manual provided the copyright notice and this permission notice are
+.\" preserved on all copies.
+.\"
+.\" Permission is granted to copy and distribute modified versions of this
+.\" manual under the conditions for verbatim copying, provided that the
+.\" entire resulting derived work is distributed under the terms of a
+.\" permission notice identical to this one.
+.\"
+.\" Since the Linux kernel and libraries are constantly changing, this
+.\" manual page may be incorrect or out-of-date. The author(s) assume no
+.\" responsibility for errors or omissions, or for damages resulting from
+.\" the use of the information contained herein. The author(s) may not
+.\" have taken the same level of care in the production of this manual,
+.\" which is licensed free of charge, as they might when working
+.\" professionally.
+.\"
+.\" Formatted or processed versions of this manual, if unaccompanied by
+.\" the source, must acknowledge the copyright and authors of this work.
+.\" %%%LICENSE_END
+.\"
+.TH LANDLOCK 7 2021-06-27 Linux "Linux Programmer's Manual"
+.SH NAME
+Landlock \- unprivileged access-control
+.SH DESCRIPTION
+Landlock is an access-control system that enables any processes to securely
+restrict themselves and their future children.
+Because Landlock is a stackable Linux Security Module (LSM),
+it makes possible to create safe security sandboxes as new security layers
+in addition to the existing system-wide access-controls.
+This kind of sandbox is expected to help mitigate the security impact of
+bugs, and unexpected or malicious behaviors in applications.
+.PP
+A Landlock security policy is a set of access rights
+(e.g., open a file in read-only, make a directory, etc.)
+tied to a file hierarchy.
+Such policy can be configured and enforced by processes for themselves
+using three system calls:
+.IP \(bu 2
+.BR landlock_create_ruleset (2)
+creates a new ruleset;
+.IP \(bu
+.BR landlock_add_rule (2)
+adds a new rule to a ruleset;
+.IP \(bu
+.BR landlock_restrict_self (2)
+enforces a ruleset on the calling thread.
+.PP
+To be able to use these system calls,
+the running kernel must support Landlock and it must be enabled at boot
+time.
+.\"
+.SS Landlock rules
+A Landlock rule describes an action on an object.
+An object is currently a file hierarchy,
+and the related filesystem actions are defined with access rights (see
+.BR landlock_add_rule (2)).
+A set of rules is aggregated in a ruleset, which can
+then restrict the thread enforcing it, and its future children.
+.\"
+.SS Filesystem actions
+These flags enable to restrict a sandboxed process to a set of actions on
+files and directories.
+Files or directories opened before the sandboxing are not subject to these
+restrictions.
+See
+.BR landlock_add_rule (2)
+and
+.BR landlock_create_ruleset (2)
+for more context.
+.PP
+A file can only receive these access rights:
+.TP
+.B LANDLOCK_ACCESS_FS_EXECUTE
+Execute a file.
+.TP
+.B LANDLOCK_ACCESS_FS_WRITE_FILE
+Open a file with write access.
+.TP
+.B LANDLOCK_ACCESS_FS_READ_FILE
+Open a file with read access.
+.PP
+A directory can receive access rights related to files or directories.
+The following access right is applied to the directory itself,
+and the directories beneath it:
+.TP
+.B LANDLOCK_ACCESS_FS_READ_DIR
+Open a directory or list its content.
+.PP
+However,
+the following access rights only apply to the content of a directory,
+not the directory itself:
+.TP
+.B LANDLOCK_ACCESS_FS_REMOVE_DIR
+Remove an empty directory or rename one.
+.TP
+.B LANDLOCK_ACCESS_FS_REMOVE_FILE
+Unlink (or rename) a file.
+.TP
+.B LANDLOCK_ACCESS_FS_MAKE_CHAR
+Create (or rename or link) a character device.
+.TP
+.B LANDLOCK_ACCESS_FS_MAKE_DIR
+Create (or rename) a directory.
+.TP
+.B LANDLOCK_ACCESS_FS_MAKE_REG
+Create (or rename or link) a regular file.
+.TP
+.B LANDLOCK_ACCESS_FS_MAKE_SOCK
+Create (or rename or link) a UNIX domain socket.
+.TP
+.B LANDLOCK_ACCESS_FS_MAKE_FIFO
+Create (or rename or link) a named pipe.
+.TP
+.B LANDLOCK_ACCESS_FS_MAKE_BLOCK
+Create (or rename or link) a block device.
+.TP
+.B LANDLOCK_ACCESS_FS_MAKE_SYM
+Create (or rename or link) a symbolic link.
+.\"
+.SS Layers of file path access rights
+Each time a thread enforces a ruleset on itself, it updates its Landlock
+domain with a new layer of policy.
+Indeed, this complementary policy is composed with the potentially other
+rulesets already restricting this thread.
+A sandboxed thread can then safely add more constraints to itself with a
+new enforced ruleset.
+.PP
+One policy layer grants access to a file path if at least one of its rules
+encountered on the path grants the access.
+A sandboxed thread can only access a file path if all its enforced policy
+layers grant the access as well as all the other system access controls
+(e.g., filesystem DAC, other LSM policies, etc.).
+.\"
+.SS Bind mounts and OverlayFS
+Landlock enables restricting access to file hierarchies,
+which means that these access rights can be propagated with bind mounts
+(cf.
+.BR mount_namespaces (7))
+but not with OverlayFS.
+.PP
+A bind mount mirrors a source file hierarchy to a destination.
+The destination hierarchy is then composed of the exact same files,
+on which Landlock rules can be tied, either via the source or the
+destination path.
+These rules restrict access when they are encountered on a path,
+which means that they can restrict access to multiple file hierarchies at
+the same time,
+whether these hierarchies are the result of bind mounts or not.
+.PP
+An OverlayFS mount point consists of upper and lower layers.
+These layers are combined in a merge directory, result of the mount point.
+This merge hierarchy may include files from the upper and lower layers,
+but modifications performed on the merge hierarchy only reflects on the
+upper layer.
+From a Landlock policy point of view,
+each OverlayFS layers and merge hierarchies are standalone and contains
+their own set of files and directories,
+which is different from bind mounts.
+A policy restricting an OverlayFS layer will not restrict the resulted
+merged hierarchy, and vice versa.
+Landlock users should then only think about file hierarchies they want to
+allow access to, regardless of the underlying filesystem.
+.\"
+.SS Inheritance
+Every new thread resulting from a
+.BR clone (2)
+inherits Landlock domain restrictions from its parent.
+This is similar to the
+.BR seccomp (2)
+inheritance or any other LSM dealing with task's
+.BR credentials (7).
+For instance, one process's thread may apply Landlock rules to itself,
+but they will not be automatically applied to other sibling threads
+(unlike POSIX thread credential changes, cf.
+.BR nptl (7)).
+.PP
+When a thread sandboxes itself, we have the guarantee that the related
+security policy will stay enforced on all this thread's descendants.
+This allows creating standalone and modular security policies per
+application,
+which will automatically be composed between themselves according to their
+runtime parent policies.
+.\"
+.SS Ptrace restrictions
+A sandboxed process has less privileges than a non-sandboxed process and
+must then be subject to additional restrictions when manipulating another
+process.
+To be allowed to use
+.BR ptrace (2)
+and related syscalls on a target process,
+a sandboxed process should have a subset of the target process rules,
+which means the tracee must be in a sub-domain of the tracer.
+.SH VERSIONS
+Landlock was added in Linux 5.13.
+.SH NOTES
+Landlock is enabled by CONFIG_SECURITY_LANDLOCK.
+The
+.IR lsm=lsm1,...,lsmN
+command line parameter controls the sequence of the initialization of
+Linux Security Modules.
+It must contain the string
+.IR landlock
+to enable Landlock.
+If the command line parameter is not specified,
+the initialization falls back to the value of the deprecated
+.IR security=
+command line parameter and further to the value of CONFIG_LSM.
+We can check that Landlock is enabled by looking for
+.IR "landlock: Up and running."
+in kernel logs.
+.PP
+It is currently not possible to restrict some file-related actions
+accessible through these syscall families:
+.BR chdir (2),
+.BR truncate (2),
+.BR stat (2),
+.BR flock (2),
+.BR chmod (2),
+.BR chown (2),
+.BR setxattr (2),
+.BR utime (2),
+.BR ioctl (2),
+.BR fcntl (2),
+.BR access (2).
+Future Landlock evolutions will enable to restrict them.
+.SH EXAMPLES
+We first need to create the ruleset that will contain our rules.
+For this example,
+the ruleset will contain rules that only allow read actions,
+but write actions will be denied.
+The ruleset then needs to handle both of these kind of actions.
+See below for the description of filesystem actions.
+.PP
+.in +4n
+.EX
+int ruleset_fd;
+struct landlock_ruleset_attr ruleset_attr = {
+ .handled_access_fs =
+ LANDLOCK_ACCESS_FS_EXECUTE |
+ LANDLOCK_ACCESS_FS_WRITE_FILE |
+ LANDLOCK_ACCESS_FS_READ_FILE |
+ LANDLOCK_ACCESS_FS_READ_DIR |
+ LANDLOCK_ACCESS_FS_REMOVE_DIR |
+ LANDLOCK_ACCESS_FS_REMOVE_FILE |
+ LANDLOCK_ACCESS_FS_MAKE_CHAR |
+ LANDLOCK_ACCESS_FS_MAKE_DIR |
+ LANDLOCK_ACCESS_FS_MAKE_REG |
+ LANDLOCK_ACCESS_FS_MAKE_SOCK |
+ LANDLOCK_ACCESS_FS_MAKE_FIFO |
+ LANDLOCK_ACCESS_FS_MAKE_BLOCK |
+ LANDLOCK_ACCESS_FS_MAKE_SYM,
+};
+
+ruleset_fd = landlock_create_ruleset(&ruleset_attr, sizeof(ruleset_attr), 0);
+if (ruleset_fd < 0) {
+ perror("Failed to create a ruleset");
+ return 1;
+}
+.EE
+.in
+.PP
+We can now add a new rule to this ruleset thanks to the returned file
+descriptor referring to this ruleset.
+The rule will only allow reading the file hierarchy
+.IR /usr .
+Without another rule, write actions would then be denied by the ruleset.
+To add
+.IR /usr
+to the ruleset, we open it with the
+.IR O_PATH
+flag and fill the
+.IR "struct landlock_path_beneath_attr"
+with this file descriptor.
+.PP
+.in +4n
+.EX
+int err;
+struct landlock_path_beneath_attr path_beneath = {
+ .allowed_access =
+ LANDLOCK_ACCESS_FS_EXECUTE |
+ LANDLOCK_ACCESS_FS_READ_FILE |
+ LANDLOCK_ACCESS_FS_READ_DIR,
+};
+
+path_beneath.parent_fd = open("/usr", O_PATH | O_CLOEXEC);
+if (path_beneath.parent_fd < 0) {
+ perror("Failed to open file");
+ close(ruleset_fd);
+ return 1;
+}
+err = landlock_add_rule(ruleset_fd, LANDLOCK_RULE_PATH_BENEATH,
+ &path_beneath, 0);
+close(path_beneath.parent_fd);
+if (err) {
+ perror("Failed to update ruleset");
+ close(ruleset_fd);
+ return 1;
+}
+.EE
+.in
+.PP
+We now have a ruleset with one rule allowing read access to
+.IR /usr
+while denying all other handled accesses for the filesystem.
+The next step is to restrict the current thread from gaining more
+privileges
+(e.g., thanks to a set-user-ID binary).
+.PP
+.in +4n
+.EX
+if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {
+ perror("Failed to restrict privileges");
+ close(ruleset_fd);
+ return 1;
+}
+.EE
+.in
+.PP
+The current thread is now ready to sandbox itself with the ruleset.
+.PP
+.in +4n
+.EX
+if (landlock_restrict_self(ruleset_fd, 0)) {
+ perror("Failed to enforce ruleset");
+ close(ruleset_fd);
+ return 1;
+}
+close(ruleset_fd);
+.EE
+.in
+.PP
+If the
+.BR landlock_restrict_self (2)
+system call succeeds, the current thread is now restricted and this policy
+will be enforced on all its subsequently created children as well.
+Once a thread is landlocked, there is no way to remove its security policy;
+only adding more restrictions is allowed.
+These threads are now in a new Landlock domain, merge of their parent one
+(if any) with the new ruleset.
+.PP
+Full working code can be found in
+.UR https://git.kernel.org\:/pub\:/scm\:/linux\:/kernel\:/git\:/stable\:/linux.git\:/tree\:/samples\:/landlock\:/sandboxer.c
+.UE
+.SH SEE ALSO
+.BR landlock_create_ruleset (2),
+.BR landlock_add_rule (2),
+.BR landlock_restrict_self (2)
+.PP
+.UR https://landlock.io\:/
+.UE
--
2.32.0
^ permalink raw reply related
* [PATCH v2 0/4] Add Landlock man pages
From: Mickaël Salaün @ 2021-07-12 15:57 UTC (permalink / raw)
To: Alejandro Colomar, Michael Kerrisk
Cc: Mickaël Salaün, Jann Horn, Jonathan Corbet, Kees Cook,
Randy Dunlap, Vincent Dagonneau, landlock, linux-kernel,
linux-man, linux-security-module, Mickaël Salaün
From: Mickaël Salaün <mic@linux.microsoft.com>
Hi,
These four documents give a global overview of Landlock and explain each
system calls. This is mainly a formatting of the current kernel
documentation with some new additional details.
This second patch series slightly improves the content and fixes some
syntax issues pointed out by Alejandro Colomar.
This patch series can be found in a Git repository:
https://github.com/landlock-lsm/man-pages/commits/landlock-v2
Previous version:
https://lore.kernel.org/linux-man/20210706182217.32338-1-mic@digikod.net/
Regards,
Mickaël Salaün (4):
landlock.7: Add a new page to introduce Landlock
landlock_create_ruleset.2: Document new syscall
landlock_add_rule.2: Document new syscall
landlock_restrict_self.2: Document new syscall
man2/landlock_add_rule.2 | 139 +++++++++++++
man2/landlock_create_ruleset.2 | 136 +++++++++++++
man2/landlock_restrict_self.2 | 130 ++++++++++++
man7/landlock.7 | 356 +++++++++++++++++++++++++++++++++
4 files changed, 761 insertions(+)
create mode 100644 man2/landlock_add_rule.2
create mode 100644 man2/landlock_create_ruleset.2
create mode 100644 man2/landlock_restrict_self.2
create mode 100644 man7/landlock.7
base-commit: 33248cfe50ebb8762208e7ef3264676dad71b016
--
2.32.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox