Message-ID: <CAEjxPJ6-jHha+CeqSdQ2O0bpyQe_9buj2ENZz6FNj6S87XSSfg@mail.gmail.com>
Date:   Mon, 20 Jul 2020 13:49:43 -0400
From:   Stephen Smalley <stephen.smalley.work@...il.com>
To:     Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>
Cc:     Mimi Zohar <zohar@...ux.ibm.com>,
        Casey Schaufler <casey@...aufler-ca.com>,
        James Morris <jmorris@...ei.org>,
        linux-integrity@...r.kernel.org,
        SElinux list <selinux@...r.kernel.org>,
        LSM List <linux-security-module@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 4/5] LSM: Define SELinux function to measure security state

On Mon, Jul 20, 2020 at 1:40 PM Stephen Smalley
<stephen.smalley.work@...il.com> wrote:
>
> On Mon, Jul 20, 2020 at 1:34 PM Lakshmi Ramasubramanian
> <nramas@...ux.microsoft.com> wrote:
> >
> > On 7/20/20 10:06 AM, Stephen Smalley wrote:
> >
> > >> The above will ensure the following sequence will be measured:
> > >>    #1 State A - Measured
> > >>    #2 Change from State A to State B - Measured
> > >>    #3 Change from State B back to State A - Since the measured data is
> > >> same as in #1, the change will be measured only if the event name is
> > >> different between #1 and #3
> > >
> > > Perhaps the timestamp / sequence number should be part of the hashed
> > > data instead of the event name?
> >
> > If the timestamp/seqno is part of the hashed data, on every call to
> > measure IMA will add a new entry in the IMA log. This would fill up the
> > IMA log - even when there is no change in the measured data.
> >
> > To avoid that I keep the last measurement in SELinux and measure only
> > when there is a change with the timestamp in the event name.
> >
> > > I can see the appraiser wanting to know two things:
> > > 1) The current state of the system (e.g. is it enforcing, is the
> > > currently loaded policy the expected one?).
> > > 2) Has the system ever been in an unexpected state (e.g. was it
> > > temporarily switched to permissive or had an unexpected policy
> > > loaded?)
> >
> > Yes - you are right.
> > The appraiser will have to look at the entire IMA log (and the
> > corresponding TPM PCR data) to know the above.
> >
> > Time t0 => State of the system measured
> > Time tn => State changed and the new state measured
> > Time tm => State changed again and the new state measured.
> >
> > Say, the measurement at "Time tn" was an illegal change, the appraiser
> > would know.
> >
> > >
> > > I applied the patch series on top of the next-integrity branch, added
> > > measure func=LSM_STATE to ima-policy, and booted that kernel.  I get
> > > the following entries in ascii_runtime_measurements, but seemingly
> > > missing the final field:
> > >
> > > 10 8a09c48af4f8a817f59b495bd82971e096e2e367 ima-ng
> > > sha256:21c3d7b09b62b4d0b3ed15ba990f816b94808f90b76787bfae755c4b3a44cd24
> > > selinux-state
> > > 10 e610908931d70990a2855ddb33c16af2d82ce56a ima-ng
> > > sha256:c8898652afd5527ef4eaf8d85f5fee1d91fcccee34bc97f6e55b96746bedb318
> > > selinux-policy-hash
> > >
> > > Thus, I cannot verify. What am I missing?
> > >
> >
> > Looks like the template used is ima-ng which doesn't include the
> > measured buffer. Please set template to "ima-buf" in the policy.
> >
> > For example,
> > measure func=LSM_STATE template=ima-buf
>
> It seems like one shouldn't need to manually specify it if it is the
> only template that yields a useful result for the LSM_STATE function?

Actually, if we used ima-ng template for selinux-policy-hash, then
instead of needing to hash the policy
first and passing the hash to IMA, we could just pass the policy as
the buffer and IMA would take care of the hashing, right?
And we only need to use ima-buf for the selinux-state if we want the
measurement list to include the string value that
was hashed; if we just want to compare against a known-good, it would
suffice to use ima-ng for it as well, right?

Powered by blists - more mailing lists