This moves the trivial hard-coded stacking of IMA LSM hooks into the
existing LSM infrastructure.
Cc: Paul Moore <[email protected]>
Cc: James Morris <[email protected]>
Cc: "Serge E. Hallyn" <[email protected]>
Cc: Mimi Zohar <[email protected]>
Cc: Dmitry Kasatkin <[email protected]>
Cc: "Mickaël Salaün" <[email protected]>
Cc: Petr Vorel <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Takashi Iwai <[email protected]>
Cc: Jonathan McDowell <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Kees Cook <[email protected]>
---
include/linux/ima.h | 50 -----------------------------
security/integrity/ima/ima_main.c | 40 +++++++++++++++++-------
security/security.c | 52 ++++++-------------------------
3 files changed, 37 insertions(+), 105 deletions(-)
diff --git a/include/linux/ima.h b/include/linux/ima.h
index 81708ca0ebc7..3c641cc65270 100644
--- a/include/linux/ima.h
+++ b/include/linux/ima.h
@@ -16,20 +16,10 @@ struct linux_binprm;
#ifdef CONFIG_IMA
extern enum hash_algo ima_get_current_hash_algo(void);
-extern int ima_bprm_check(struct linux_binprm *bprm);
extern int ima_file_check(struct file *file, int mask);
extern void ima_post_create_tmpfile(struct user_namespace *mnt_userns,
struct inode *inode);
extern void ima_file_free(struct file *file);
-extern int ima_file_mmap(struct file *file, unsigned long prot);
-extern int ima_file_mprotect(struct vm_area_struct *vma, unsigned long prot);
-extern int ima_load_data(enum kernel_load_data_id id, bool contents);
-extern int ima_post_load_data(char *buf, loff_t size,
- enum kernel_load_data_id id, char *description);
-extern int ima_read_file(struct file *file, enum kernel_read_file_id id,
- bool contents);
-extern int ima_post_read_file(struct file *file, void *buf, loff_t size,
- enum kernel_read_file_id id);
extern void ima_post_path_mknod(struct user_namespace *mnt_userns,
struct dentry *dentry);
extern int ima_file_hash(struct file *file, char *buf, size_t buf_size);
@@ -56,11 +46,6 @@ static inline enum hash_algo ima_get_current_hash_algo(void)
return HASH_ALGO__LAST;
}
-static inline int ima_bprm_check(struct linux_binprm *bprm)
-{
- return 0;
-}
-
static inline int ima_file_check(struct file *file, int mask)
{
return 0;
@@ -76,41 +61,6 @@ static inline void ima_file_free(struct file *file)
return;
}
-static inline int ima_file_mmap(struct file *file, unsigned long prot)
-{
- return 0;
-}
-
-static inline int ima_file_mprotect(struct vm_area_struct *vma,
- unsigned long prot)
-{
- return 0;
-}
-
-static inline int ima_load_data(enum kernel_load_data_id id, bool contents)
-{
- return 0;
-}
-
-static inline int ima_post_load_data(char *buf, loff_t size,
- enum kernel_load_data_id id,
- char *description)
-{
- return 0;
-}
-
-static inline int ima_read_file(struct file *file, enum kernel_read_file_id id,
- bool contents)
-{
- return 0;
-}
-
-static inline int ima_post_read_file(struct file *file, void *buf, loff_t size,
- enum kernel_read_file_id id)
-{
- return 0;
-}
-
static inline void ima_post_path_mknod(struct user_namespace *mnt_userns,
struct dentry *dentry)
{
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index e617863af5ff..2cff001b02e4 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -395,6 +395,7 @@ static int process_measurement(struct file *file, const struct cred *cred,
/**
* ima_file_mmap - based on policy, collect/store measurement.
* @file: pointer to the file to be measured (May be NULL)
+ * @reqprot: contains the protection that will be applied by the kernel.
* @prot: contains the protection that will be applied by the kernel.
*
* Measure files being mmapped executable based on the ima_must_measure()
@@ -403,11 +404,12 @@ static int process_measurement(struct file *file, const struct cred *cred,
* On success return 0. On integrity appraisal error, assuming the file
* is in policy and IMA-appraisal is in enforcing mode, return -EACCES.
*/
-int ima_file_mmap(struct file *file, unsigned long prot)
+static int ima_file_mmap(struct file *file, unsigned long reqprot,
+ unsigned long prot, unsigned long flags)
{
u32 secid;
- if (file && (prot & PROT_EXEC)) {
+ if (file && (reqprot & PROT_EXEC)) {
security_current_getsecid_subj(&secid);
return process_measurement(file, current_cred(), secid, NULL,
0, MAY_EXEC, MMAP_CHECK);
@@ -419,6 +421,7 @@ int ima_file_mmap(struct file *file, unsigned long prot)
/**
* ima_file_mprotect - based on policy, limit mprotect change
* @vma: vm_area_struct protection is set to
+ * @reqprot: contains the protection that were requested.
* @prot: contains the protection that will be applied by the kernel.
*
* Files can be mmap'ed read/write and later changed to execute to circumvent
@@ -429,7 +432,8 @@ int ima_file_mmap(struct file *file, unsigned long prot)
*
* On mprotect change success, return 0. On failure, return -EACESS.
*/
-int ima_file_mprotect(struct vm_area_struct *vma, unsigned long prot)
+static int ima_file_mprotect(struct vm_area_struct *vma,
+ unsigned long reqprot, unsigned long prot)
{
struct ima_template_desc *template = NULL;
struct file *file;
@@ -483,7 +487,7 @@ int ima_file_mprotect(struct vm_area_struct *vma, unsigned long prot)
* On success return 0. On integrity appraisal error, assuming the file
* is in policy and IMA-appraisal is in enforcing mode, return -EACCES.
*/
-int ima_bprm_check(struct linux_binprm *bprm)
+static int ima_bprm_check(struct linux_binprm *bprm)
{
int ret;
u32 secid;
@@ -706,8 +710,8 @@ void ima_post_path_mknod(struct user_namespace *mnt_userns,
*
* For permission return 0, otherwise return -EACCES.
*/
-int ima_read_file(struct file *file, enum kernel_read_file_id read_id,
- bool contents)
+static int ima_read_file(struct file *file, enum kernel_read_file_id read_id,
+ bool contents)
{
enum ima_hooks func;
u32 secid;
@@ -756,8 +760,8 @@ const int read_idmap[READING_MAX_ID] = {
* On success return 0. On integrity appraisal error, assuming the file
* is in policy and IMA-appraisal is in enforcing mode, return -EACCES.
*/
-int ima_post_read_file(struct file *file, void *buf, loff_t size,
- enum kernel_read_file_id read_id)
+static int ima_post_read_file(struct file *file, char *buf, loff_t size,
+ enum kernel_read_file_id read_id)
{
enum ima_hooks func;
u32 secid;
@@ -790,7 +794,7 @@ int ima_post_read_file(struct file *file, void *buf, loff_t size,
*
* For permission return 0, otherwise return -EACCES.
*/
-int ima_load_data(enum kernel_load_data_id id, bool contents)
+static int ima_load_data(enum kernel_load_data_id id, bool contents)
{
bool ima_enforce, sig_enforce;
@@ -844,9 +848,9 @@ int ima_load_data(enum kernel_load_data_id id, bool contents)
* On success return 0. On integrity appraisal error, assuming the file
* is in policy and IMA-appraisal is in enforcing mode, return -EACCES.
*/
-int ima_post_load_data(char *buf, loff_t size,
- enum kernel_load_data_id load_id,
- char *description)
+static int ima_post_load_data(char *buf, loff_t size,
+ enum kernel_load_data_id load_id,
+ char *description)
{
if (load_id == LOADING_FIRMWARE) {
if ((ima_appraise & IMA_APPRAISE_FIRMWARE) &&
@@ -1077,6 +1081,18 @@ static int __init init_ima(void)
late_initcall(init_ima); /* Start IMA after the TPM is available */
+static struct security_hook_list ima_hooks[] __lsm_ro_after_init = {
+ LSM_HOOK_INIT(bprm_check_security, ima_bprm_check),
+ LSM_HOOK_INIT(mmap_file, ima_file_mmap),
+ LSM_HOOK_INIT(file_mprotect, ima_file_mprotect),
+ LSM_HOOK_INIT(kernel_read_file, ima_read_file),
+ LSM_HOOK_INIT(kernel_post_read_file, ima_post_read_file),
+ LSM_HOOK_INIT(kernel_load_data, ima_load_data),
+ LSM_HOOK_INIT(kernel_post_load_data, ima_post_load_data),
+};
+
void __init integrity_lsm_ima_init(void)
{
+ pr_info("Integrity LSM enabling IMA\n");
+ integrity_add_lsm_hooks(ima_hooks, ARRAY_SIZE(ima_hooks));
}
diff --git a/security/security.c b/security/security.c
index 14d30fec8a00..8f7c1b5fa5fa 100644
--- a/security/security.c
+++ b/security/security.c
@@ -862,12 +862,7 @@ int security_bprm_creds_from_file(struct linux_binprm *bprm, struct file *file)
int security_bprm_check(struct linux_binprm *bprm)
{
- int ret;
-
- ret = call_int_hook(bprm_check_security, 0, bprm);
- if (ret)
- return ret;
- return ima_bprm_check(bprm);
+ return call_int_hook(bprm_check_security, 0, bprm);
}
void security_bprm_committing_creds(struct linux_binprm *bprm)
@@ -1589,12 +1584,8 @@ static inline unsigned long mmap_prot(struct file *file, unsigned long prot)
int security_mmap_file(struct file *file, unsigned long prot,
unsigned long flags)
{
- int ret;
- ret = call_int_hook(mmap_file, 0, file, prot,
- mmap_prot(file, prot), flags);
- if (ret)
- return ret;
- return ima_file_mmap(file, prot);
+ return call_int_hook(mmap_file, 0, file, prot,
+ mmap_prot(file, prot), flags);
}
int security_mmap_addr(unsigned long addr)
@@ -1605,12 +1596,7 @@ int security_mmap_addr(unsigned long addr)
int security_file_mprotect(struct vm_area_struct *vma, unsigned long reqprot,
unsigned long prot)
{
- int ret;
-
- ret = call_int_hook(file_mprotect, 0, vma, reqprot, prot);
- if (ret)
- return ret;
- return ima_file_mprotect(vma, prot);
+ return call_int_hook(file_mprotect, 0, vma, reqprot, prot);
}
int security_file_lock(struct file *file, unsigned int cmd)
@@ -1746,35 +1732,20 @@ int security_kernel_module_request(char *kmod_name)
int security_kernel_read_file(struct file *file, enum kernel_read_file_id id,
bool contents)
{
- int ret;
-
- ret = call_int_hook(kernel_read_file, 0, file, id, contents);
- if (ret)
- return ret;
- return ima_read_file(file, id, contents);
+ return call_int_hook(kernel_read_file, 0, file, id, contents);
}
EXPORT_SYMBOL_GPL(security_kernel_read_file);
int security_kernel_post_read_file(struct file *file, char *buf, loff_t size,
enum kernel_read_file_id id)
{
- int ret;
-
- ret = call_int_hook(kernel_post_read_file, 0, file, buf, size, id);
- if (ret)
- return ret;
- return ima_post_read_file(file, buf, size, id);
+ return call_int_hook(kernel_post_read_file, 0, file, buf, size, id);
}
EXPORT_SYMBOL_GPL(security_kernel_post_read_file);
int security_kernel_load_data(enum kernel_load_data_id id, bool contents)
{
- int ret;
-
- ret = call_int_hook(kernel_load_data, 0, id, contents);
- if (ret)
- return ret;
- return ima_load_data(id, contents);
+ return call_int_hook(kernel_load_data, 0, id, contents);
}
EXPORT_SYMBOL_GPL(security_kernel_load_data);
@@ -1782,13 +1753,8 @@ int security_kernel_post_load_data(char *buf, loff_t size,
enum kernel_load_data_id id,
char *description)
{
- int ret;
-
- ret = call_int_hook(kernel_post_load_data, 0, buf, size, id,
- description);
- if (ret)
- return ret;
- return ima_post_load_data(buf, size, id, description);
+ return call_int_hook(kernel_post_load_data, 0, buf, size, id,
+ description);
}
EXPORT_SYMBOL_GPL(security_kernel_post_load_data);
--
2.34.1
On Thu, 2022-10-13 at 15:36 -0700, Kees Cook wrote:
> This moves the trivial hard-coded stacking of IMA LSM hooks into the
> existing LSM infrastructure.
The only thing trivial about making IMA and EVM LSMs is moving them to
LSM hooks. Although static files may be signed and the signatures
distributed with the file data through the normal distribution
mechanisms (e.g. RPM), other files cannot be signed remotely (e.g.
configuration files). For these files, both IMA and EVM may be
configured to maintain persistent file state stored as security xattrs
in the form of security.ima file hashes or security.evm HMACs. The LSM
flexibility of enabling/disabling IMA or EVM on a per boot basis breaks
this usage, potentially preventing subsequent boots.
--
thanks,
Mimi
On Wed, Oct 19, 2022 at 10:34:48AM -0400, Mimi Zohar wrote:
> On Thu, 2022-10-13 at 15:36 -0700, Kees Cook wrote:
> > This moves the trivial hard-coded stacking of IMA LSM hooks into the
> > existing LSM infrastructure.
>
> The only thing trivial about making IMA and EVM LSMs is moving them to
> LSM hooks. Although static files may be signed and the signatures
> distributed with the file data through the normal distribution
> mechanisms (e.g. RPM), other files cannot be signed remotely (e.g.
> configuration files). For these files, both IMA and EVM may be
> configured to maintain persistent file state stored as security xattrs
> in the form of security.ima file hashes or security.evm HMACs. The LSM
> flexibility of enabling/disabling IMA or EVM on a per boot basis breaks
> this usage, potentially preventing subsequent boots.
I'm not suggesting IMA and EVM don't have specific behaviors that need to
be correctly integrated into the LSM infrastructure. In fact, I spent a
lot of time designing that infrastructure to be flexible enough to deal
with these kinds of things. (e.g. plumbing "enablement", etc.) As I
mentioned, this was more of trying to provide a head-start on the
conversion. I don't intend to drive this -- please take whatever is
useful from this example and use it. :) I'm happy to help construct any
missing infrastructure needed (e.g. LSM_ORDER_LAST, etc).
As for preventing subsequent boots, this is already true with other LSMs
that save state that affects system behavior (like SELinux tags, AppArmor
policy). IMA and EVM are not special in that regard conceptually.
Besides, it also looks like it's already possible to boot with IMA or EVM
disabled ("ima_appraise=off", or "evm=fix"), so there's no regression
conceptually for having "integrity" get dropped from the lsm= list at
boot. And if you want it not to be silent disabling, that's fine --
just panic during initialization if "integrity" is disabled, as is
already happening.
Note that, generally speaking, LSMs have three initialization points:
LSM init, fs_initcall, and late_initcall:
$ grep -R _initcall security/*/ | wc -l
31
This, again, isn't different for IMA or EVM. The LSM infrastructure is
about gathering and standardizing the requirements needed to run security
hooks in a common way. The goal isn't to break IMA/EVM -- anything
needed can be created for it. The goal is to remove _exceptions_ to the
common hook mechanism.
BTW, are there examples of how to test an IMA/EVM system? I couldn't
find any pre-existing test images one can boot in QEMU, or instructions
on how to create such an image, but I could have missed it.
--
Kees Cook
On Wed, 2022-10-19 at 11:59 -0700, Kees Cook wrote:
> On Wed, Oct 19, 2022 at 10:34:48AM -0400, Mimi Zohar wrote:
> > On Thu, 2022-10-13 at 15:36 -0700, Kees Cook wrote:
> > > This moves the trivial hard-coded stacking of IMA LSM hooks into the
> > > existing LSM infrastructure.
> >
> > The only thing trivial about making IMA and EVM LSMs is moving them to
> > LSM hooks. Although static files may be signed and the signatures
> > distributed with the file data through the normal distribution
> > mechanisms (e.g. RPM), other files cannot be signed remotely (e.g.
> > configuration files). For these files, both IMA and EVM may be
> > configured to maintain persistent file state stored as security xattrs
> > in the form of security.ima file hashes or security.evm HMACs. The LSM
> > flexibility of enabling/disabling IMA or EVM on a per boot basis breaks
> > this usage, potentially preventing subsequent boots.
>
> I'm not suggesting IMA and EVM don't have specific behaviors that need to
> be correctly integrated into the LSM infrastructure. In fact, I spent a
> lot of time designing that infrastructure to be flexible enough to deal
> with these kinds of things. (e.g. plumbing "enablement", etc.) As I
> mentioned, this was more of trying to provide a head-start on the
> conversion. I don't intend to drive this -- please take whatever is
> useful from this example and use it. :) I'm happy to help construct any
> missing infrastructure needed (e.g. LSM_ORDER_LAST, etc).
>
> As for preventing subsequent boots, this is already true with other LSMs
> that save state that affects system behavior (like SELinux tags, AppArmor
> policy). IMA and EVM are not special in that regard conceptually.
> Besides, it also looks like it's already possible to boot with IMA or EVM
> disabled ("ima_appraise=off", or "evm=fix"), so there's no regression
> conceptually for having "integrity" get dropped from the lsm= list at
> boot. And if you want it not to be silent disabling, that's fine --
> just panic during initialization if "integrity" is disabled, as is
> already happening.
Being able to specify "ima_appraise=" on the boot command line requires
IMA_APPRAISE_BOOTPARAM to be configured. Even when specified, if the
system is booted with secure-boot mode enabled, it also cannot be
modified. With the ability of randomly enabling/disabling LSMs, these
protections are useless.
>
> Note that, generally speaking, LSMs have three initialization points:
> LSM init, fs_initcall, and late_initcall:
IMA initialization is deferred to late_initcall to allow the TPM to
finish initializing. It doesn't make a difference when the iint_cache
is initialized. It just needs to be prior to IMA/EVM initializiation.
>
> $ grep -R _initcall security/*/ | wc -l
> 31
>
> This, again, isn't different for IMA or EVM. The LSM infrastructure is
> about gathering and standardizing the requirements needed to run security
> hooks in a common way. The goal isn't to break IMA/EVM -- anything
> needed can be created for it. The goal is to remove _exceptions_ to the
> common hook mechanism.
>
> BTW, are there examples of how to test an IMA/EVM system? I couldn't
> find any pre-existing test images one can boot in QEMU, or instructions
> on how to create such an image, but I could have missed it.
There are specific tests in LTP, kselftests, and ima-evm-utils, but
they are incomplete.
On Wed, Oct 19, 2022 at 04:45:41PM -0400, Mimi Zohar wrote:
> On Wed, 2022-10-19 at 11:59 -0700, Kees Cook wrote:
> > On Wed, Oct 19, 2022 at 10:34:48AM -0400, Mimi Zohar wrote:
> > > On Thu, 2022-10-13 at 15:36 -0700, Kees Cook wrote:
> > > > This moves the trivial hard-coded stacking of IMA LSM hooks into the
> > > > existing LSM infrastructure.
> > >
> > > The only thing trivial about making IMA and EVM LSMs is moving them to
> > > LSM hooks. Although static files may be signed and the signatures
> > > distributed with the file data through the normal distribution
> > > mechanisms (e.g. RPM), other files cannot be signed remotely (e.g.
> > > configuration files). For these files, both IMA and EVM may be
> > > configured to maintain persistent file state stored as security xattrs
> > > in the form of security.ima file hashes or security.evm HMACs. The LSM
> > > flexibility of enabling/disabling IMA or EVM on a per boot basis breaks
> > > this usage, potentially preventing subsequent boots.
> >
> > I'm not suggesting IMA and EVM don't have specific behaviors that need to
> > be correctly integrated into the LSM infrastructure. In fact, I spent a
> > lot of time designing that infrastructure to be flexible enough to deal
> > with these kinds of things. (e.g. plumbing "enablement", etc.) As I
> > mentioned, this was more of trying to provide a head-start on the
> > conversion. I don't intend to drive this -- please take whatever is
> > useful from this example and use it. :) I'm happy to help construct any
> > missing infrastructure needed (e.g. LSM_ORDER_LAST, etc).
> >
> > As for preventing subsequent boots, this is already true with other LSMs
> > that save state that affects system behavior (like SELinux tags, AppArmor
> > policy). IMA and EVM are not special in that regard conceptually.
>
> > Besides, it also looks like it's already possible to boot with IMA or EVM
> > disabled ("ima_appraise=off", or "evm=fix"), so there's no regression
> > conceptually for having "integrity" get dropped from the lsm= list at
> > boot. And if you want it not to be silent disabling, that's fine --
> > just panic during initialization if "integrity" is disabled, as is
> > already happening.
>
> Being able to specify "ima_appraise=" on the boot command line requires
> IMA_APPRAISE_BOOTPARAM to be configured. Even when specified, if the
> system is booted with secure-boot mode enabled, it also cannot be
> modified. With the ability of randomly enabling/disabling LSMs, these
> protections are useless.
Sure, so let's get lsm= added to the lockdown list, etc. My point is for
us to work through each of these concerns and address them. I am not an
IMA/EVM expert, but I do understand the LSM infrastructure deeply, so
I'd like to help you get these changes made.
--
Kees Cook
On Wed, 2022-10-19 at 16:41 -0700, Kees Cook wrote:
> On Wed, Oct 19, 2022 at 04:45:41PM -0400, Mimi Zohar wrote:
> > On Wed, 2022-10-19 at 11:59 -0700, Kees Cook wrote:
> > > On Wed, Oct 19, 2022 at 10:34:48AM -0400, Mimi Zohar wrote:
> > > > On Thu, 2022-10-13 at 15:36 -0700, Kees Cook wrote:
> > > > > This moves the trivial hard-coded stacking of IMA LSM hooks into the
> > > > > existing LSM infrastructure.
> > > >
> > > > The only thing trivial about making IMA and EVM LSMs is moving them to
> > > > LSM hooks. Although static files may be signed and the signatures
> > > > distributed with the file data through the normal distribution
> > > > mechanisms (e.g. RPM), other files cannot be signed remotely (e.g.
> > > > configuration files). For these files, both IMA and EVM may be
> > > > configured to maintain persistent file state stored as security xattrs
> > > > in the form of security.ima file hashes or security.evm HMACs. The LSM
> > > > flexibility of enabling/disabling IMA or EVM on a per boot basis breaks
> > > > this usage, potentially preventing subsequent boots.
> > >
> > > I'm not suggesting IMA and EVM don't have specific behaviors that need to
> > > be correctly integrated into the LSM infrastructure. In fact, I spent a
> > > lot of time designing that infrastructure to be flexible enough to deal
> > > with these kinds of things. (e.g. plumbing "enablement", etc.) As I
> > > mentioned, this was more of trying to provide a head-start on the
> > > conversion. I don't intend to drive this -- please take whatever is
> > > useful from this example and use it. :) I'm happy to help construct any
> > > missing infrastructure needed (e.g. LSM_ORDER_LAST, etc).
> > >
> > > As for preventing subsequent boots, this is already true with other LSMs
> > > that save state that affects system behavior (like SELinux tags, AppArmor
> > > policy). IMA and EVM are not special in that regard conceptually.
> >
> > > Besides, it also looks like it's already possible to boot with IMA or EVM
> > > disabled ("ima_appraise=off", or "evm=fix"), so there's no regression
> > > conceptually for having "integrity" get dropped from the lsm= list at
> > > boot. And if you want it not to be silent disabling, that's fine --
> > > just panic during initialization if "integrity" is disabled, as is
> > > already happening.
> >
> > Being able to specify "ima_appraise=" on the boot command line requires
> > IMA_APPRAISE_BOOTPARAM to be configured. Even when specified, if the
> > system is booted with secure-boot mode enabled, it also cannot be
> > modified. With the ability of randomly enabling/disabling LSMs, these
> > protections are useless.
>
> Sure, so let's get lsm= added to the lockdown list, etc.
I thought the move to "lsm=" was to allow different LSMs to be
enabled/disabled at run time. Adding "lsm=" to the lockdown list
doesn't seem like the correct solution to limiting which LSMs can be
enabled/disabled at runtime. As I recall, lockdown needs to be enabled
by userspace.
> My point is for
> us to work through each of these concerns and address them. I am not an
> IMA/EVM expert, but I do understand the LSM infrastructure deeply, so
> I'd like to help you get these changes made.
Sure
--
thanks,
Mimi
On 10/21/2022 7:53 AM, Dr. Greg wrote:
> On Wed, Oct 19, 2022 at 11:59:40AM -0700, Kees Cook wrote:
>
> Good morning, I hope the week is ending well for everyone.
>
>> On Wed, Oct 19, 2022 at 10:34:48AM -0400, Mimi Zohar wrote:
>>> The only thing trivial about making IMA and EVM LSMs is moving
>>> them to LSM hooks. Although static files may be signed and the
>>> signatures distributed with the file data through the normal
>>> distribution mechanisms (e.g. RPM), other files cannot be signed
>>> remotely (e.g. configuration files). For these files, both IMA
>>> and EVM may be configured to maintain persistent file state stored
>>> as security xattrs in the form of security.ima file hashes or
>>> security.evm HMACs. The LSM flexibility of enabling/disabling IMA
>>> or EVM on a per boot basis breaks this usage, potentially
>>> preventing subsequent boots.
>> I'm not suggesting IMA and EVM don't have specific behaviors that
>> need to be correctly integrated into the LSM infrastructure. In
>> fact, I spent a lot of time designing that infrastructure to be
>> flexible enough to deal with these kinds of things. (e.g. plumbing
>> "enablement", etc.) As I mentioned, this was more of trying to
>> provide a head-start on the conversion. I don't intend to drive this
>> -- please take whatever is useful from this example and use it. :)
>> I'm happy to help construct any missing infrastructure needed
>> (e.g. LSM_ORDER_LAST, etc).
> We are 2-3 weeks out from submitting for review and inclusion in the
> kernel, a new LSM, and an associated userspace stack, that will have a
> high degree of significance with respect to these conversations.
Oh, come on, No one likes a teaser trailer. ;)
>
>> Kees Cook
> Best wishes for a pleasant fall weekend.
>
> As always,
>
> Dr. Greg
> The Quixote Project - Flailing at the Travails of Cybersecurity
On Wed, Oct 19, 2022 at 11:59:40AM -0700, Kees Cook wrote:
Good morning, I hope the week is ending well for everyone.
> On Wed, Oct 19, 2022 at 10:34:48AM -0400, Mimi Zohar wrote:
> >
> > The only thing trivial about making IMA and EVM LSMs is moving
> > them to LSM hooks. Although static files may be signed and the
> > signatures distributed with the file data through the normal
> > distribution mechanisms (e.g. RPM), other files cannot be signed
> > remotely (e.g. configuration files). For these files, both IMA
> > and EVM may be configured to maintain persistent file state stored
> > as security xattrs in the form of security.ima file hashes or
> > security.evm HMACs. The LSM flexibility of enabling/disabling IMA
> > or EVM on a per boot basis breaks this usage, potentially
> > preventing subsequent boots.
> I'm not suggesting IMA and EVM don't have specific behaviors that
> need to be correctly integrated into the LSM infrastructure. In
> fact, I spent a lot of time designing that infrastructure to be
> flexible enough to deal with these kinds of things. (e.g. plumbing
> "enablement", etc.) As I mentioned, this was more of trying to
> provide a head-start on the conversion. I don't intend to drive this
> -- please take whatever is useful from this example and use it. :)
> I'm happy to help construct any missing infrastructure needed
> (e.g. LSM_ORDER_LAST, etc).
We are 2-3 weeks out from submitting for review and inclusion in the
kernel, a new LSM, and an associated userspace stack, that will have a
high degree of significance with respect to these conversations.
> Kees Cook
Best wishes for a pleasant fall weekend.
As always,
Dr. Greg
The Quixote Project - Flailing at the Travails of Cybersecurity