lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 05 Aug 2020 08:56:59 -0400
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Stephen Smalley <stephen.smalley.work@...il.com>,
        Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>,
        casey@...aufler-ca.com
Cc:     tyhicks@...ux.microsoft.com, sashal@...nel.org, jmorris@...ei.org,
        linux-integrity@...r.kernel.org, selinux@...r.kernel.org,
        linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 1/4] IMA: Add func to measure LSM state and policy

On Wed, 2020-08-05 at 08:46 -0400, Stephen Smalley wrote:
> On 8/4/20 11:25 PM, Mimi Zohar wrote:
> 
> > Hi Lakshmi,
> > 
> > There's still  a number of other patch sets needing to be reviewed
> > before my getting to this one.  The comment below is from a high level.
> > 
> > On Tue, 2020-08-04 at 17:43 -0700, Lakshmi Ramasubramanian wrote:
> > > Critical data structures of security modules need to be measured to
> > > enable an attestation service to verify if the configuration and
> > > policies for the security modules have been setup correctly and
> > > that they haven't been tampered with at runtime. A new IMA policy is
> > > required for handling this measurement.
> > > 
> > > Define two new IMA policy func namely LSM_STATE and LSM_POLICY to
> > > measure the state and the policy provided by the security modules.
> > > Update ima_match_rules() and ima_validate_rule() to check for
> > > the new func and ima_parse_rule() to handle the new func.
> > I can understand wanting to measure the in kernel LSM memory state to
> > make sure it hasn't changed, but policies are stored as files.  Buffer
> > measurements should be limited  to those things that are not files.
> > 
> > Changing how data is passed to the kernel has been happening for a
> > while.  For example, instead of passing the kernel module or kernel
> > image in a buffer, the new syscalls - finit_module, kexec_file_load -
> > pass an open file descriptor.  Similarly, instead of loading the IMA
> > policy data, a pathname may be provided.
> > 
> > Pre and post security hooks already exist for reading files.   Instead
> > of adding IMA support for measuring the policy file data, update the
> > mechanism for loading the LSM policy.  Then not only will you be able
> > to measure the policy, you'll also be able to require the policy be
> > signed.
> 
> To clarify, the policy being measured by this patch series is a 
> serialized representation of the in-memory policy data structures being 
> enforced by SELinux.  Not the file that was loaded.  Hence, this 
> measurement would detect tampering with the in-memory policy data 
> structures after the policy has been loaded.  In the case of SELinux, 
> one can read this serialized representation via /sys/fs/selinux/policy.  
> The result is not byte-for-byte identical to the policy file that was 
> loaded but can be semantically compared via sediff and other tools to 
> determine whether it is equivalent.

Thank you for the clarification.   Could the policy hash be included
with the other critical data?  Does it really need to be measured
independently?

Mimi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ