Re: [PATCH v16 01/20] security: add ipe lsm

On 3/28/24 13:45, Jarkko Sakkinen wrote: >> +/** >> + * ipe_init - Entry point of IPE. >> + * >> + * This is called at LSM init, which happens occurs early during kernel >> + * start up. During this phase, IPE registers its hooks and loads the >> + * builtin boot policy. >> + * Return: >> + * *

Re: [PATCH v16 03/20] ipe: add evaluation loop

On Thu Mar 28, 2024 at 10:17 PM EET, Fan Wu wrote: > From: Deven Bowers > > IPE must have a centralized function to evaluate incoming callers > against IPE's policy. This iteration of the policy for against the rules > for that specific caller is known as the evaluation loop. > > Signed-off-by:

Re: [PATCH v16 02/20] ipe: add policy parser

On Thu Mar 28, 2024 at 10:17 PM EET, Fan Wu wrote: > From: Deven Bowers > > IPE's interpretation of the what the user trusts is accomplished through > its policy. IPE's design is to not provide support for a single trust > provider, but to support multiple providers to enable the end-user to >

Re: [PATCH v16 02/20] ipe: add policy parser

On Thu Mar 28, 2024 at 10:17 PM EET, Fan Wu wrote: > From: Deven Bowers > > IPE's interpretation of the what the user trusts is accomplished through > its policy. IPE's design is to not provide support for a single trust > provider, but to support multiple providers to enable the end-user to >

Re: [PATCH v16 01/20] security: add ipe lsm

On Thu Mar 28, 2024 at 10:17 PM EET, Fan Wu wrote: > From: Deven Bowers > > Integrity Policy Enforcement (IPE) is an LSM that provides an > complimentary approach to Mandatory Access Control than existing LSMs > today. > > Existing LSMs have centered around the concept of access to a resource >

Re: [PATCH v16 00/20] Integrity Policy Enforcement LSM (IPE)

On Thu Mar 28, 2024 at 10:36 PM EET, Jarkko Sakkinen wrote: > On Thu Mar 28, 2024 at 10:17 PM EET, Fan Wu wrote: > > Overview: > > - > > s/:// > > It is already a heading. > > > > > IPE is a Linux Security Module which takes a complimentary approach to > > Integrity Policy Enforcement

Re: [PATCH v16 00/20] Integrity Policy Enforcement LSM (IPE)

On Thu Mar 28, 2024 at 10:17 PM EET, Fan Wu wrote: > Overview: > - s/:// It is already a heading. > > IPE is a Linux Security Module which takes a complimentary approach to Integrity Policy Enforcement (IPE) is a ... > access control. Whereas existing mandatory access control

[PATCH v16 20/20] documentation: add ipe documentation

From: Deven Bowers Add IPE's admin and developer documentation to the kernel tree. Co-developed-by: Fan Wu Signed-off-by: Deven Bowers Signed-off-by: Fan Wu --- v2: + No Changes v3: + Add Acked-by + Fixup code block syntax + Fix a minor grammatical issue. v4: + Update

[PATCH v16 09/20] uapi|audit|ipe: add ipe auditing support

From: Deven Bowers Users of IPE require a way to identify when and why an operation fails, allowing them to both respond to violations of policy and be notified of potentially malicious actions on their systems with respect to IPE itself. This patch introduces 3 new audit events.

[PATCH v16 19/20] ipe: kunit test for parser

From: Deven Bowers Add various happy/unhappy unit tests for both IPE's policy parser. Besides, a test suite for IPE functionality is available at https://github.com/microsoft/ipe/tree/test-suite Signed-off-by: Deven Bowers Signed-off-by: Fan Wu --- v1-v6: + Not present v7: Introduced

[PATCH v16 18/20] scripts: add boot policy generation program

From: Deven Bowers Enables an IPE policy to be enforced from kernel start, enabling access control based on trust from kernel startup. This is accomplished by transforming an IPE policy indicated by CONFIG_IPE_BOOT_POLICY into a c-string literal that is parsed at kernel startup as an unsigned

[PATCH v16 16/20] fsverity: consume fsverity built-in signatures via LSM hook

This patch enhances fsverity's capabilities to support both integrity and authenticity protection by introducing the consumption of built-in signatures through a new LSM hook. This functionality allows LSMs, e.g. IPE, to enforce policies based on the authenticity and integrity of files,

[PATCH v16 11/20] block|security: add LSM blob to block_device

From: Deven Bowers Some block devices have valuable security properties that is only accessible during the creation time. For example, when creating a dm-verity block device, the dm-verity's roothash and roothash signature, which are extreme important security metadata, are passed to the

[PATCH v16 14/20] ipe: add support for dm-verity as a trust provider

From: Deven Bowers Allows author of IPE policy to indicate trust for a singular dm-verity volume, identified by roothash, through "dmverity_roothash" and all signed dm-verity volumes, through "dmverity_signature". Signed-off-by: Deven Bowers Signed-off-by: Fan Wu --- v2: + No Changes v3:

[PATCH v16 17/20] ipe: enable support for fs-verity as a trust provider

Enable IPE policy authors to indicate trust for a singular fsverity file, identified by the digest information, through "fsverity_digest" and all files using fsverity's builtin signatures via "fsverity_signature". This enables file-level integrity claims to be expressed in IPE, allowing

[PATCH v16 15/20] security: add security_inode_setintegrity() hook

This patch introduces a new hook to save inode's integrity data. For example, for fsverity enabled files, LSMs can use this hook to save the verified fsverity builtin signature into the inode's security blob, and LSMs can make access decisions based on the data inside the signature, like the

[PATCH v16 12/20] dm: add finalize hook to target_type

This patch adds a target finalize hook. The hook is triggered just before activating an inactive table of a mapped device. If it returns an error the __bind get cancelled. The dm-verity target will use this hook to attach the dm-verity's roothash metadata to the block_device struct of the mapped

[PATCH v16 08/20] ipe: add userspace interface

From: Deven Bowers As is typical with LSMs, IPE uses securityfs as its interface with userspace. for a complete list of the interfaces and the respective inputs/outputs, please see the documentation under admin-guide/LSM/ipe.rst Signed-off-by: Deven Bowers Signed-off-by: Fan Wu --- v2: +

[PATCH v16 13/20] dm verity: consume root hash digest and signature data via LSM hook

From: Deven Bowers dm-verity provides a strong guarantee of a block device's integrity. As a generic way to check the integrity of a block device, it provides those integrity guarantees to its higher layers, including the filesystem level. An LSM that control access to a resource on the system

[PATCH v16 07/20] security: add new securityfs delete function

When deleting a directory in the security file system, the existing securityfs_remove requires the directory to be empty, otherwise it will do nothing. This leads to a potential risk that the security file system might be in an unclean state when the intended deletion did not happen. This commit

[PATCH v16 10/20] ipe: add permissive toggle

From: Deven Bowers IPE, like SELinux, supports a permissive mode. This mode allows policy authors to test and evaluate IPE policy without it effecting their programs. When the mode is changed, a 1404 AUDIT_MAC_STATUS be reported. This patch adds the following audit records: audit:

[PATCH v16 06/20] ipe: introduce 'boot_verified' as a trust provider

IPE is designed to provide system level trust guarantees, this usually implies that trust starts from bootup with a hardware root of trust, which validates the bootloader. After this, the bootloader verifies the kernel and the initramfs. As there's no currently supported integrity method for

[PATCH v16 05/20] initramfs|security: Add a security hook to do_populate_rootfs()

This patch introduces a new hook to notify security system that the content of initramfs has been unpacked into the rootfs. Upon receiving this notification, the security system can activate a policy to allow only files that originated from the initramfs to execute or load into kernel during the

[PATCH v16 00/20] Integrity Policy Enforcement LSM (IPE)

Overview: - IPE is a Linux Security Module which takes a complimentary approach to access control. Whereas existing mandatory access control mechanisms base their decisions on labels and paths, IPE instead determines whether or not an operation should be allowed based on immutable

[PATCH v16 02/20] ipe: add policy parser

From: Deven Bowers IPE's interpretation of the what the user trusts is accomplished through its policy. IPE's design is to not provide support for a single trust provider, but to support multiple providers to enable the end-user to choose the best one to seek their needs. This requires the

[PATCH v16 04/20] ipe: add LSM hooks on execution and kernel read

From: Deven Bowers IPE's initial goal is to control both execution and the loading of kernel modules based on the system's definition of trust. It accomplishes this by plugging into the security hooks for bprm_check_security, file_mprotect, mmap_file, kernel_load_data, and kernel_read_data.

[PATCH v16 01/20] security: add ipe lsm

From: Deven Bowers Integrity Policy Enforcement (IPE) is an LSM that provides an complimentary approach to Mandatory Access Control than existing LSMs today. Existing LSMs have centered around the concept of access to a resource should be controlled by the current user's credentials. IPE's

[PATCH v16 03/20] ipe: add evaluation loop

From: Deven Bowers IPE must have a centralized function to evaluate incoming callers against IPE's policy. This iteration of the policy for against the rules for that specific caller is known as the evaluation loop. Signed-off-by: Deven Bowers Signed-off-by: Fan Wu --- v2: + Split evaluation

Re: [syzbot] [audit?] [bpf?] INFO: rcu detected stall in kauditd_thread (4)

On Wed 2024-03-27 15:16:25, Paul Moore wrote: > On Wed, Mar 27, 2024 at 2:39 PM syzbot > wrote: > > > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit:fe46a7dd189e Merge tag 'sound-6.9-rc1' of git://git.kernel.. > > git tree: upstream > > console output: