| Message ID | 20200613024130.3356-6-nramas@linux.microsoft.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | LSM: Measure security module state | expand |
On Fri, Jun 12, 2020 at 10:42 PM Lakshmi Ramasubramanian <nramas@linux.microsoft.com> wrote: > > The data maintained by the security modules could be tampered with by > malware. The LSM needs to periodically query the state of > the security modules and measure the data when the state is changed. > > Define a workqueue for handling this periodic query and measurement. Won't this make it difficult/impossible to predict the IMA PCR value? Unless I missed it, you are going to end up measuring every N minutes even if there was no change and therefore constantly be extending the PCR. That will break attestation or sealing against the IMA PCR.
On Mon, 2020-06-15 at 09:33 -0400, Stephen Smalley wrote: > On Fri, Jun 12, 2020 at 10:42 PM Lakshmi Ramasubramanian > <nramas@linux.microsoft.com> wrote: > > > > The data maintained by the security modules could be tampered with by > > malware. The LSM needs to periodically query the state of > > the security modules and measure the data when the state is changed. > > > > Define a workqueue for handling this periodic query and measurement. > > Won't this make it difficult/impossible to predict the IMA PCR value? > Unless I missed it, you are going to end up measuring every N minutes > even if there was no change and therefore constantly be extending the > PCR. That will break attestation or sealing against the IMA PCR. Even if it attempts to add the same measurement to the list multiple times, unless something changed, there should only be one measurement in the list. Mimi
On Mon, Jun 15, 2020 at 10:59 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Mon, 2020-06-15 at 09:33 -0400, Stephen Smalley wrote: > > On Fri, Jun 12, 2020 at 10:42 PM Lakshmi Ramasubramanian > > <nramas@linux.microsoft.com> wrote: > > > > > > The data maintained by the security modules could be tampered with by > > > malware. The LSM needs to periodically query the state of > > > the security modules and measure the data when the state is changed. > > > > > > Define a workqueue for handling this periodic query and measurement. > > > > Won't this make it difficult/impossible to predict the IMA PCR value? > > Unless I missed it, you are going to end up measuring every N minutes > > even if there was no change and therefore constantly be extending the > > PCR. That will break attestation or sealing against the IMA PCR. > > Even if it attempts to add the same measurement to the list multiple > times, unless something changed, there should only be one measurement > in the list. Is the PCR only extended once?
On Mon, 2020-06-15 at 11:47 -0400, Stephen Smalley wrote: > On Mon, Jun 15, 2020 at 10:59 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > On Mon, 2020-06-15 at 09:33 -0400, Stephen Smalley wrote: > > > On Fri, Jun 12, 2020 at 10:42 PM Lakshmi Ramasubramanian > > > <nramas@linux.microsoft.com> wrote: > > > > > > > > The data maintained by the security modules could be tampered with by > > > > malware. The LSM needs to periodically query the state of > > > > the security modules and measure the data when the state is changed. > > > > > > > > Define a workqueue for handling this periodic query and measurement. > > > > > > Won't this make it difficult/impossible to predict the IMA PCR value? > > > Unless I missed it, you are going to end up measuring every N minutes > > > even if there was no change and therefore constantly be extending the > > > PCR. That will break attestation or sealing against the IMA PCR. > > > > Even if it attempts to add the same measurement to the list multiple > > times, unless something changed, there should only be one measurement > > in the list. > > Is the PCR only extended once? Yes, otherwise you wouldn't be able to verify a quote. ima_lookup_digest_entry() first verifies the hash isn't in the cache, before adding it to the measurement list and then extending the TPM. Mimi
diff --git a/security/security.c b/security/security.c index e7175db5a093..3dad6766cb9d 100644 --- a/security/security.c +++ b/security/security.c @@ -89,6 +89,11 @@ static __initdata struct lsm_info *exclusive; static struct lsm_info *security_state_lsms; static int security_state_lsms_count; +static long security_state_timeout = 300000; /* 5 Minutes */ +static void security_state_handler(struct work_struct *work); +static DECLARE_DELAYED_WORK(security_state_delayed_work, + security_state_handler); + static __initdata bool debug; #define init_debug(...) \ do { \ @@ -294,6 +299,26 @@ static void __init initialize_security_state_lsms(void) security_state_lsms_count = count; } +static void initialize_security_state_monitor(void) +{ + if (security_state_lsms_count == 0) + return; + + schedule_delayed_work(&security_state_delayed_work, + msecs_to_jiffies(security_state_timeout)); +} + +static void security_state_handler(struct work_struct *work) +{ + int inx; + + for (inx = 0; inx < security_state_lsms_count; inx++) + measure_security_state(&(security_state_lsms[inx])); + + schedule_delayed_work(&security_state_delayed_work, + msecs_to_jiffies(security_state_timeout)); +} + /* Populate ordered LSMs list from comma-separated LSM name list. */ static void __init ordered_lsm_parse(const char *order, const char *origin) { @@ -417,6 +442,7 @@ static void __init ordered_lsm_init(void) } initialize_security_state_lsms(); + initialize_security_state_monitor(); kfree(ordered_lsms); }
The data maintained by the security modules could be tampered with by malware. The LSM needs to periodically query the state of the security modules and measure the data when the state is changed. Define a workqueue for handling this periodic query and measurement. Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com> --- security/security.c | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+)