On 2020-12-11 4:25 p.m., Tyler Hicks wrote:
On 2020-12-11 15:58:03, Tushar Sugandhi wrote:
A new IMA policy rule is needed for the IMA hook
ima_measure_critical_data() and the corresponding func CRITICAL_DATA for
measuring the input buffer. The policy rule should ensure the buffer
would get m
The IMA hook ima_measure_critical_data() does not support a way to
specify the source of the critical data provider. Thus, the data
measurement cannot be constrained based on the data source label
in the IMA policy.
Extend the IMA hook ima_measure_critical_data() to support passing
the data sourc
From: Lakshmi Ramasubramanian
Define a new critical data builtin policy to allow measuring
early kernel integrity critical data before a custom IMA policy
is loaded.
Add critical data to built-in IMA rules if the kernel command line
contains "ima_policy=critical_data".
Update the documentation
From: Lakshmi Ramasubramanian
SELinux stores the active policy in memory, so the changes to this data
at runtime would have an impact on the security guarantees provided
by SELinux. Measuring in-memory SELinux policy through IMA subsystem
provides a secure way for the attestation service to remot
IMA measures files and buffer data such as keys, command-line arguments
passed to the kernel on kexec system call, etc. While these measurements
are necessary for monitoring and validating the integrity of the system,
they are not sufficient. Various data structures, policies, and states
stored in
System administrators should be able to limit which kernel subsystems
they want to measure the critical data for. To enable that, an IMA policy
condition to choose specific kernel subsystems is needed. This policy
condition would constrain the measurement of the critical data based on
a label for t
The original IMA buffer data measurement sizes were small (e.g. boot
command line), but the new buffer data measurement use cases have data
sizes that are a lot larger. Just as IMA measures the file data hash,
not the file data, IMA should similarly support the option for measuring
the hash of t
IMA functions such as ima_match_keyring(), process_buffer_measurement(),
ima_match_policy() etc. handle data specific to keyrings. Currently,
these constructs are not generic to handle any func specific data.
This makes it harder to extend them without code duplication.
Refactor the keyring specif
IMA provides capabilities to measure file data, and in-memory buffer
data. However, various data structures, policies, and states
stored in kernel memory also impact the integrity of the system.
Several kernel subsystems contain such integrity critical data. These
kernel subsystems help protect the
A new IMA policy rule is needed for the IMA hook
ima_measure_critical_data() and the corresponding func CRITICAL_DATA for
measuring the input buffer. The policy rule should ensure the buffer
would get measured only when the policy rule allows the action. The
policy rule should also support the nece
On 12/11/20 6:04 PM, Jens Axboe wrote:
On 12/11/20 9:56 AM, Hannes Reinecke wrote:
On 12/11/20 5:33 PM, Jens Axboe wrote:
On 12/11/20 9:30 AM, Mike Snitzer wrote:
While I still think there needs to be a proper _upstream_ consumer of
blk_interposer as a condition of it going in.. I'll let other
+ */
+void ima_measure_critical_data(const char *event_name,
+ const void *buf, int buf_len,
+ bool measure_buf_hash)
+{
+ if (!event_name || !buf || !buf_len) {
+ pr_err("Invalid arguments passed to %s().\n", __func_
On 12/11/20 9:56 AM, Hannes Reinecke wrote:
> On 12/11/20 5:33 PM, Jens Axboe wrote:
>> On 12/11/20 9:30 AM, Mike Snitzer wrote:
>>> While I still think there needs to be a proper _upstream_ consumer of
>>> blk_interposer as a condition of it going in.. I'll let others make the
>>> call.
>>
>> That
On Fri, 11 Dec 2020, Johannes Thumshirn wrote:
> On 11/12/2020 15:57, SelvaKumar S wrote:
> [...]
> > +int blk_copy_emulate(struct block_device *bdev, struct blk_copy_payload
> > *payload,
> > + gfp_t gfp_mask)
> > +{
> > + struct request_queue *q = bdev_get_queue(bdev);
> > + s
On 12/11/20 5:33 PM, Jens Axboe wrote:
On 12/11/20 9:30 AM, Mike Snitzer wrote:
While I still think there needs to be a proper _upstream_ consumer of
blk_interposer as a condition of it going in.. I'll let others make the
call.
That's an unequivocal rule.
As such, I'll defer to Jens, Christo
On 12/11/20 9:30 AM, Mike Snitzer wrote:
> While I still think there needs to be a proper _upstream_ consumer of
> blk_interposer as a condition of it going in.. I'll let others make the
> call.
That's an unequivocal rule.
> As such, I'll defer to Jens, Christoph and others on whether your
> mini
On Thu, Dec 10 2020 at 11:32am -0500,
Mike Snitzer wrote:
> On Thu, Dec 10 2020 at 9:58am -0500,
> Sergei Shtepa wrote:
>
> > The 12/09/2020 16:51, Mike Snitzer wrote:
> > > On Wed, Dec 09 2020 at 8:01am -0500,
> > > Sergei Shtepa wrote:
> > >
> > > > Hi all.
> > > >
> > > > I try to sugge
On 11/12/2020 15:57, SelvaKumar S wrote:
[...]
> +int blk_copy_emulate(struct block_device *bdev, struct blk_copy_payload
> *payload,
> + gfp_t gfp_mask)
> +{
> + struct request_queue *q = bdev_get_queue(bdev);
> + struct bio *bio;
> + void *buf = NULL;
> + int i, nr_s
On 2020-12-10 17:21:19, Tushar Sugandhi wrote:
>
>
> On 2020-12-10 2:38 p.m., Tyler Hicks wrote:
> > On 2020-12-09 11:42:06, Tushar Sugandhi wrote:
> > > The original IMA buffer data measurement sizes were small (e.g. boot
> > > command line), but the new buffer data measurement use cases have da
On 2020-12-09 11:42:10, Tushar Sugandhi wrote:
> The IMA hook ima_measure_critical_data() does not support a way to
> specify the source of the critical data provider. Thus, the data
> measurement cannot be constrained based on the data source label
> in the IMA policy.
>
> Extend the IMA hook ima
On 2020-12-09 11:42:11, Tushar Sugandhi wrote:
> From: Lakshmi Ramasubramanian
>
> Define a new critical data builtin policy to allow measuring
> early kernel integrity critical data before a custom IMA policy
> is loaded.
>
> Add critical data to built-in IMA rules if the kernel command line
>
On 2020-12-09 11:42:09, Tushar Sugandhi wrote:
> System administrators should be able to limit which kernel subsystems
> they want to measure the critical data for. To enable that, an IMA policy
> condition to choose specific kernel subsystems is needed. This policy
> condition would constrain the
On 2020-12-09 11:42:08, Tushar Sugandhi wrote:
> A new IMA policy rule is needed for the IMA hook
> ima_measure_critical_data() and the corresponding func CRITICAL_DATA for
> measuring the input buffer. The policy rule should ensure the buffer
> would get measured only when the policy rule allows t
On 2020-12-09 11:42:06, Tushar Sugandhi wrote:
> The original IMA buffer data measurement sizes were small (e.g. boot
> command line), but the new buffer data measurement use cases have data
> sizes that are a lot larger. Just as IMA measures the file data hash,
> not the file data, IMA should si
On 2020-12-09 11:42:05, Tushar Sugandhi wrote:
> IMA functions such as ima_match_keyring(), process_buffer_measurement(),
> ima_match_policy() etc. handle data specific to keyrings. Currently,
> these constructs are not generic to handle any func specific data.
> This makes it harder to extend them
On 2020-12-09 11:42:07, Tushar Sugandhi wrote:
> IMA provides capabilities to measure file data, and in-memory buffer
> data. However, various data structures, policies, and states
> stored in kernel memory also impact the integrity of the system.
> Several kernel subsystems contain such integrity
26 matches
Mail list logo
