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 pol
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.
AUDIT_IPE_ACCE
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.
Sign
From: Deven Bowers
Add various happy/unhappy unit tests for both IPE's parser.
Signed-off-by: Deven Bowers
Signed-off-by: Fan Wu
---
v1-v6:
+ Not present
v7:
Introduced
v8:
+ Remove the kunit tests with respect to the fsverity digest, as these
require significant changes to work w
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 intentded deletion
did not happen.
This commit
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:
+ Sp
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: MAC_STATU
fsverity represents a mechanism to support both integrity and
authenticity protection of a file, supporting both signed and unsigned
digests.
An LSM which controls access to a resource based on authenticity and
integrity of said resource, can then use this data to make an informed
decision on the
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 kernel.
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
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 b
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 individual
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
security
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
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 documentatio
The device-mapper has a flag to mark targets as singleton, which is a
required flag for immutable targets. Without this flag, multiple
dm-verity targets can be added to a mapped device, which has no
practical use cases and will let dm_table_get_immutable_target return
NULL. This patch adds the miss
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 polic
From: Deven Bowers
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 integ
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 appro
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:
On 10/4/23 15:09, Fan Wu wrote:
| diff --git a/security/ipe/Kconfig b/security/ipe/Kconfig
| index 7afb1ce0cb99..9dd5c4769d79 100644
| --- a/security/ipe/Kconfig
| +++ b/security/ipe/Kconfig
| @@ -30,6 +30,19 @@ config IPE_PROP_DM_VERITY
| that was mounted with a signed root-hash or the
On Wed, Oct 04, 2023 at 03:09:42PM -0700, Fan Wu wrote:
> +#ifdef CONFIG_FS_VERITY_BUILTIN_SIGNATURES
> +static int fsverity_inode_setsecurity(struct inode *inode,
> + struct fsverity_descriptor *desc)
> +{
> + return security_inode_setsecurity(inode, FS_VERITY
On 10/4/2023 4:58 PM, Randy Dunlap wrote:
On 10/4/23 15:09, Fan Wu wrote:
| diff --git a/security/ipe/Kconfig b/security/ipe/Kconfig
| index 7afb1ce0cb99..9dd5c4769d79 100644
| --- a/security/ipe/Kconfig
| +++ b/security/ipe/Kconfig
| @@ -30,6 +30,19 @@ config IPE_PROP_DM_VERITY
| t
On 10/4/2023 7:27 PM, Eric Biggers wrote:
On Wed, Oct 04, 2023 at 03:09:42PM -0700, Fan Wu wrote:
+#ifdef CONFIG_FS_VERITY_BUILTIN_SIGNATURES
+static int fsverity_inode_setsecurity(struct inode *inode,
+ struct fsverity_descriptor *desc)
+{
+ return s
Hi,
在 2023/09/29 2:45, Song Liu 写道:
On Wed, Sep 27, 2023 at 11:22 PM Yu Kuai wrote:
From: Yu Kuai
Advantages for new apis:
- reconfig_mutex is not required;
- the weird logical that suspend array hold 'reconfig_mutex' for
mddev_check_recovery() to update superblock is not needed;
Hi,
在 2023/09/29 3:15, Song Liu 写道:
Hi Kuai,
Thanks for the patchset!
A few high level questions/suggestions:
Thanks a lot for these!
1. This is a big change that needs a lot of explanation. While you managed to
keep each patch relatively small (great job btw), it is not very clear why we
On Wed, Oct 4, 2023 at 7:59 PM Yu Kuai wrote:
>
> Hi,
>
> 在 2023/09/29 2:45, Song Liu 写道:
> > On Wed, Sep 27, 2023 at 11:22 PM Yu Kuai wrote:
> >>
> >> From: Yu Kuai
> >>
> >> Advantages for new apis:
> >> - reconfig_mutex is not required;
> >> - the weird logical that suspend array hold 're
On Wed, Oct 4, 2023 at 8:42 PM Yu Kuai wrote:
>
> Hi,
>
> 在 2023/09/29 3:15, Song Liu 写道:
> > Hi Kuai,
> >
> > Thanks for the patchset!
> >
> > A few high level questions/suggestions:
>
> Thanks a lot for these!
> >
> > 1. This is a big change that needs a lot of explanation. While you managed
>
28 matches
Mail list logo
