[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2df1bc4f-675d-7868-de5b-1256346f982e@schaufler-ca.com>
Date: Mon, 15 Jun 2020 10:33:06 -0700
From: Casey Schaufler <casey@...aufler-ca.com>
To: Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>,
Stephen Smalley <stephen.smalley.work@...il.com>
Cc: Mimi Zohar <zohar@...ux.ibm.com>,
Stephen Smalley <stephen.smalley@...il.com>,
James Morris <jmorris@...ei.org>,
linux-integrity@...r.kernel.org,
LSM List <linux-security-module@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH 4/5] LSM: Define SELinux function to measure security
state
On 6/15/2020 9:45 AM, Lakshmi Ramasubramanian wrote:
> On 6/15/20 4:57 AM, Stephen Smalley wrote:
>
> Hi Stephen,
>
> Thanks for reviewing the patches.
>
>>> +void security_state_change(char *lsm_name, void *state, int state_len)
>>> +{
>>> + ima_lsm_state(lsm_name, state, state_len);
>>> +}
>>> +
>>
>> What's the benefit of this trivial function instead of just calling
>> ima_lsm_state() directly?
>
> One of the feedback Casey Schaufler had given earlier was that calling an IMA function directly from SELinux (or, any of the Security Modules) would be a layering violation.
Hiding the ima_lsm_state() call doesn't address the layering.
The point is that SELinux code being called from IMA (or the
other way around) breaks the subsystem isolation. Unfortunately,
it isn't obvious to me how you would go about what you're doing
without integrating the subsystems.
>
> LSM framework (security/security.c) already calls IMA functions now (for example, ima_bprm_check() is called from security_bprm_check()). I followed the same pattern for measuring LSM data as well.
>
> Please let me know if I misunderstood Casey's comment.
>
Powered by blists - more mailing lists