6 files changed, 149 insertions(+), 11 deletions(-)
> create mode 100644 security/selinux/ima.c
> create mode 100644 security/selinux/include/ima.h
I remain concerned about the possibility of bypassing a measurement by
tampering with the time, but I appear to be the only one who is
worried a
serspace applications are dependent
> on it. Unless everyone is on board that removing the timestamp
> wouldn't be considered a regression, it cannot be upstreamed.
I'm not a fan of merging things which are known to be broken only with
the promise of fixing it later. That goes double when the proper fix
will result in a user visible breaking change.
--
paul moore
www.paul-moore.com
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
On Wed, Jan 13, 2021 at 2:13 PM Mimi Zohar wrote:
> On Tue, 2021-01-12 at 11:27 -0500, Paul Moore wrote:
> > On Thu, Jan 7, 2021 at 11:07 PM Tushar Sugandhi
> > wrote:
> > > From: Lakshmi Ramasubramanian
> > >
> > > SELinux stores the active pol
On Wed, Jan 13, 2021 at 4:11 PM Mimi Zohar wrote:
> On Wed, 2021-01-13 at 14:19 -0500, Paul Moore wrote:
> > On Wed, Jan 13, 2021 at 2:13 PM Mimi Zohar wrote:
> > > On Tue, 2021-01-12 at 11:27 -0500, Paul Moore wrote:
> > > > On Thu, Jan 7, 2021 at 11:07 PM
On Wed, Jan 13, 2021 at 6:11 PM Mimi Zohar wrote:
> On Wed, 2021-01-13 at 17:10 -0500, Paul Moore wrote:
> > On Wed, Jan 13, 2021 at 4:11 PM Mimi Zohar wrote:
> > > On Wed, 2021-01-13 at 14:19 -0500, Paul Moore wrote:
> > > > On Wed, Jan 13, 2021 at 2:13 PM Mimi
with policy_mutex held.
> + */
> +int security_read_policy_kernel(struct selinux_state *state,
> + void **data, size_t *len)
Let's call this "security_read_state_kernel()".
> +{
> + struct selinux_policy *policy;
> + int rc = 0;
See below, the rc variable is not needed.
> - *len = (unsigned long)fp.data - (unsigned long)*data;
> - return 0;
> + policy = rcu_dereference_protected(
> + state->policy, lockdep_is_held(>policy_mutex));
> + if (!policy) {
> + rc = -EINVAL;
> + goto out;
Jumping to the out label is a little silly since it is just a return;
do a "return -EINVAL;" here instead.
> + }
> +
> + *len = policy->policydb.len;
> + *data = vmalloc(*len);
> + if (!*data) {
> + rc = -ENOMEM;
> + goto out;
Same as above, "return -ENOMEM;" please.
> + }
>
> + rc = security_read_selinux_policy(policy, *data, len);
You should be able to do "return security_read_selinux_policy(...);" here.
> +
> +out:
> + return rc;
> }
--
paul moore
www.paul-moore.com
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
On Mon, Jan 4, 2021 at 6:30 PM Lakshmi Ramasubramanian
wrote:
> On 12/23/20 1:10 PM, Paul Moore wrote:
> Hi Paul,
Hello.
> >> diff --git a/security/selinux/measure.c b/security/selinux/measure.c
> >> new file mode 100644
> >> index ..b7e24358e
dev=%s op=%s error_msg='%s' res=%d"
"... module=%s dev=%s op=%s res=%d"
The first thing that jumps out is that some fields, e.g. "sector", are
not always present in the record; we typically handle this by using a
"?" for the field value in those cases where you
break;
> + }
> + audit_log_format(ab, " res=%d", result);
> + audit_log_end(ab);
> +}
> +EXPORT_SYMBOL_GPL(dm_audit_log_ti);
Just checking, but are you okay when the inevitable happens and
someone passes an @audit_type that is not either AUDIT_C
On Tue, Oct 19, 2021 at 9:15 PM Paul Moore wrote:
>
> Due to conflict with the audit and SELinux trees the device mapper
> audit record types need to be renumbered before landing in Linus'
> tree.
>
> Link:
> https://lore.kernel.org/lkml/cahc9vhtlmzdqpqsj+vybnua1x1
odule for device mapper")
Signed-off-by: Paul Moore
---
include/uapi/linux/audit.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
index 6650ab6def2a..809e4c2041b3 100644
--- a/include/uapi/linux/audit.h
+++
On Wed, Oct 27, 2021 at 4:57 PM Mike Snitzer wrote:
>
> On Tue, Oct 26 2021 at 10:22P -0400,
> Paul Moore wrote:
>
> > On Tue, Oct 19, 2021 at 9:17 PM Paul Moore wrote:
> > > On Tue, Oct 19, 2021 at 9:15 PM Paul Moore wrote:
> > > >
> > > &g
On Tue, Oct 19, 2021 at 9:17 PM Paul Moore wrote:
> On Tue, Oct 19, 2021 at 9:15 PM Paul Moore wrote:
> >
> > Due to conflict with the audit and SELinux trees the device mapper
> > audit record types need to be renumbered before landing in Linus'
> > tre
On Wed, Oct 25, 2023 at 6:46 PM Fan Wu wrote:
> On 10/23/2023 8:52 PM, Paul Moore wrote:
> > On Oct 4, 2023 Fan Wu wrote:
> >>
> >> IPE's interpretation of the what the user trusts is accomplished through
> >> its policy. IPE's design is to not provide supp
On Thu, Oct 26, 2023 at 5:33 PM Fan Wu wrote:
> On 10/23/2023 8:52 PM, Paul Moore wrote:
> > On Oct 4, 2023 Fan Wu wrote:
> >>
> >> IPE is designed to provide system level trust guarantees, this usually
> >> implies that trust starts from bootup with
On Oct 4, 2023 Fan Wu wrote:
>
> 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.
>
On Oct 4, 2023 Fan Wu wrote:
>
> 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
>
On Oct 4, 2023 Fan Wu wrote:
>
> 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
On Oct 4, 2023 Fan Wu wrote:
>
> 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
On Oct 4, 2023 Fan Wu wrote:
>
> 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
On Oct 4, 2023 Fan Wu wrote:
>
> 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
>
On Oct 4, 2023 Fan Wu wrote:
>
> 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
On Oct 4, 2023 Fan Wu wrote:
>
> 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
On Oct 4, 2023 Fan Wu wrote:
>
> 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
On Oct 4, 2023 Fan Wu wrote:
>
> 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
On Oct 4, 2023 Fan Wu wrote:
>
> 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
On Oct 4, 2023 Fan Wu wrote:
>
> 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
On Oct 4, 2023 Fan Wu wrote:
>
> 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
On Oct 4, 2023 Fan Wu wrote:
>
> Add various happy/unhappy unit tests for both IPE's parser.
I'm going to suggest: "... for IPE's policy parser."
Also, aside from the policy parser tests, are there any other IPE
functional tests? We do have a testing guideline for new LSM
submissions:
"New
On Wed, Jun 8, 2022 at 3:01 PM Deven Bowers
wrote:
>
> 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 systens with respect to IPE
> itself.
>
> The new 1420
On Wed, Jun 8, 2022 at 3:03 PM Deven Bowers
wrote:
>
> 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
On Mon, Jan 30, 2023 at 5:58 PM 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
>
On Mon, Jan 30, 2023 at 5:58 PM 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 against the rules
> for that specific caller is known as the evaluation loop.
>
> In addition, IPE is
On Mon, Jan 30, 2023 at 5:58 PM Fan Wu wrote:
>
> From: Deven Bowers
>
> block_device structures can have valuable security properties,
> based on how they are created, and what subsystem manages them.
>
> By adding LSM storage to this structure, this data can be accessed
> at the LSM layer.
>
>
On Mon, Jan 30, 2023 at 5:58 PM Fan Wu wrote:
>
> 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
On Mon, Jan 30, 2023 at 5:58 PM Fan Wu wrote:
>
> 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
>
>
On Mon, Jan 30, 2023 at 5:58 PM 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
>
On Mon, Jan 30, 2023 at 5:58 PM Fan Wu wrote:
>
> 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.
>
>
On Mon, Jan 30, 2023 at 5:59 PM Fan Wu wrote:
>
> 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,
On Tue, Jan 31, 2023 at 12:11 PM Steve Grubb wrote:
>
> Hello,
>
> On Monday, January 30, 2023 5:57:22 PM EST Fan Wu wrote:
> > 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
t(1677619596.727:1162): module=verity
> op=verify-data dev=7:0 sector=1000 res=0
>
> type=DM_EVENT msg=audit(1677619596.731:1163): module=verity
> op=max-corrupted-errors dev=254:3 sector=? res=0
>
> Signed-off-by: Michael Weiß
> ---
> drivers/md/dm-verity-target.c | 20 +
On Fri, Feb 10, 2023 at 6:21 PM Fan Wu wrote:
> On Tue, Jan 31, 2023 at 04:49:44PM +0100, Roberto Sassu wrote:
> > On Mon, 2023-01-30 at 14:57 -0800, Fan Wu wrote:
> > > From: Deven Bowers
> > >
> > > IPE must have a centralized function to evaluate incoming callers
> > > against IPE's policy.
On Mon, Apr 17, 2023 at 2:06 PM Fan Wu wrote:
> On Thu, Apr 13, 2023 at 02:45:07PM -0400, Paul Moore wrote:
> > On Wed, Apr 12, 2023 at 7:36???PM Fan Wu wrote:
> > > On Tue, Apr 11, 2023 at 05:45:41PM -0400, Paul Moore wrote:
> > > > On Mon, Apr 10, 2023 at 3:
On Mon, Apr 17, 2023 at 5:18 PM Fan Wu wrote:
> On Mon, Apr 17, 2023 at 04:16:29PM -0400, Paul Moore wrote:
> > On Mon, Apr 17, 2023 at 2:06???PM Fan Wu wrote:
> > > On Thu, Apr 13, 2023 at 02:45:07PM -0400, Paul Moore wrote:
> > > > On Wed, Apr 12, 2023 at 7:
On Thu, Apr 6, 2023 at 4:00 PM Fan Wu wrote:
> On Thu, Mar 02, 2023 at 02:02:32PM -0500, Paul Moore wrote:
> > On Mon, Jan 30, 2023 at 5:58???PM Fan Wu wrote:
> > >
> > > From: Deven Bowers
> > >
> > > IPE's interpretation of the what the user tr
On Mon, Apr 10, 2023 at 2:53 PM Fan Wu wrote:
> On Thu, Mar 02, 2023 at 02:03:11PM -0500, Paul Moore wrote:
> > On Mon, Jan 30, 2023 at 5:58???PM Fan Wu wrote:
> > >
> > > From: Deven Bowers
> > >
> > > IPE must have a centralized function to evaluat
On Thu, Mar 2, 2023 at 2:05 PM Paul Moore wrote:
> On Tue, Jan 31, 2023 at 12:11 PM Steve Grubb wrote:
> > On Monday, January 30, 2023 5:57:22 PM EST Fan Wu wrote:
...
> > > audit: MAC_POLICY_LOAD policy_name="dmverity_roothash"
> >
On Mon, Apr 10, 2023 at 3:10 PM Fan Wu wrote:
> On Thu, Mar 02, 2023 at 02:04:42PM -0500, Paul Moore wrote:
> > On Mon, Jan 30, 2023 at 5:58???PM Fan Wu wrote:
> > >
> > > From: Deven Bowers
> > >
> > > As is typical with LSMs, IPE uses sec
On Thu, Mar 16, 2023 at 6:53 PM Fan Wu wrote:
> On Thu, Mar 02, 2023 at 02:05:33PM -0500, Paul Moore wrote:
> > On Tue, Jan 31, 2023 at 12:11???PM Steve Grubb wrote:
> > >
> > > Hello,
> > >
> > > On Monday, January 30, 2023 5:57:22 PM
On Wed, Apr 12, 2023 at 7:36 PM Fan Wu wrote:
> On Tue, Apr 11, 2023 at 05:45:41PM -0400, Paul Moore wrote:
> > On Mon, Apr 10, 2023 at 3:10???PM Fan Wu wrote:
> > > On Thu, Mar 02, 2023 at 02:04:42PM -0500, Paul Moore wrote:
> > > > On Mon, Jan 30, 2023 at 5:
On Jun 28, 2023 Fan Wu wrote:
>
> 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.
>
On Jun 28, 2023 Fan Wu wrote:
>
> 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.
Can you rewrite that second sentence, it reads a bit awkward
On Jun 28, 2023 Fan Wu wrote:
>
> 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
On Jun 28, 2023 Fan Wu wrote:
>
> 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
On Jun 28, 2023 Fan Wu wrote:
>
> 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
On Jun 28, 2023 Fan Wu wrote:
>
> 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
On Jun 28, 2023 Fan Wu wrote:
>
> 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
On Jun 28, 2023 Fan Wu wrote:
>
> 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
>
On Jun 28, 2023 Fan Wu wrote:
>
> 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
On Jun 28, 2023 Fan Wu wrote:
>
> 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
>
On Jun 28, 2023 Fan Wu wrote:
>
> 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
On Jun 28, 2023 Fan Wu wrote:
>
> 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
On Jun 28, 2023 Fan Wu wrote:
>
> 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
On Jun 28, 2023 Fan Wu wrote:
>
> 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
On Jun 28, 2023 Fan Wu wrote:
>
> 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
>
On Jun 28, 2023 Fan Wu wrote:
>
> 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
On Jun 28, 2023 Fan Wu wrote:
>
> 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
On Jun 28, 2023 Fan Wu wrote:
>
> 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.
Can you rewrite that second sentence, it reads a bit awkward
On Jun 28, 2023 Fan Wu wrote:
>
> 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
>
On Jun 28, 2023 Fan Wu wrote:
>
> 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.
>
On Fri, Jul 14, 2023 at 11:26 PM Fan Wu wrote:
> On Sat, Jul 08, 2023 at 12:23:04AM -0400, Paul Moore wrote:
> > On Jun 28, 2023 Fan Wu wrote:
> > >
> > > As is typical with LSMs, IPE uses securityfs as its interface with
> > > userspace. for a complete list
On Fri, Jul 14, 2023 at 11:57 PM Fan Wu wrote:
> On Sat, Jul 08, 2023 at 12:23:05AM -0400, Paul Moore wrote:
> > On Jun 28, 2023 Fan Wu wrote:
> > >
> > > Users of IPE require a way to identify when and why an operation fails,
> > > allowing them to
On Tue, Jul 11, 2023 at 11:43 PM Fan Wu wrote:
> On Fri, Jul 07, 2023 at 10:53:45AM -0400, Mike Snitzer wrote:
...
> > Both of your calls to security_bdev_setsecurity() to set your blobs in
> > the bdev are suspect because you're doing so from the verity_ctr().
> > The mapped_device has 2
73 matches
Mail list logo
