Re: [RFC PATCH v2 0/4] tsm: Runtime measurement registers ABI

[Dr. Greg]

On Mon, Feb 12, 2024 at 11:36:27PM -0800, Xing, Cedric wrote:

Hi, I hope the week is going well for everyone.

> On 2/9/2024 12:58 PM, Dan Williams wrote:
> >James Bottomley wrote:
> >>Just to correct this: IMA uses its own log format, but I think this was
> >>a mistake long ago and the new log should use TCG2 format so all the
> >>tools know how to parse it.
> >
> >Is this a chance to nudge IMA towards a standard log format? In other
> >words, one of the goals alongside userspace consumers of the RTMR log
> >would be for IMA to support it as well as an alternate in-kernel backend
> >next to TPM. IMA-over-TPM continues with its current format,
> >IMA-over-RTMR internally unifies with the log format that is shared with
> >RTMR-user-ABI.

> I'm not a TCG expert. As far as I know,
> https://trustedcomputinggroup.org/wp-content/uploads/TCG-PC-Client-Platform-Firmware-Profile-Version-1.06-Revision-52_pub-1.pdf
> defines the event types for TCG2 logs for firmware uses only. I
> cannot find a spec that defines event types for OS or
> applications. We may reuse the firmware event types for Linux but I
> doubt they can accommodate IMA.
>
> IMHO, we don't have to follow TCG2 format because TDX is never TPM,
> nor are any other TEEs that support runtime measurements. The
> existing TCG2 format looks to me somewhat like ASN.1 - well defined
> but schema is needed to decode. In contrast, JSON is a lot more
> popular than ASN.1 nowadays because it's human readable and doesn't
> require a schema. I just wonder if we should introduce a text based
> log format. We could make the log a text file, in which each line is
> an event record and the digest of the line is extended to the
> specified runtime measurement register. The content of each line
> could be free-form at the ABI level, but we can still recommend a
> convention for applications - e.g., the first word/column must be an
> URL for readers to find out the format/syntax of the rest of the
> line. Thoughts?

A common text based security event description format, based on JSON
encoding of LSM security event descriptions, surfaced through
securityfs, has already been implemented, proposed and has been pushed
out for review twice.

The TSEM LSM is designed to be a generic security modeling and
security event description export architecture.

The V2 patches and discusion around those can be found here:

https://lore.kernel.org/lkml/20230710102319.19716-1-greg@xxxxxxxxxxxx/T/#t

We have a rather significant upgrade to that patchset that we are
staging up for a V3 release.

The fundamental premise for TSEM is the encoding and modeling of the
parameters that describe LSM based security events.  It is designed to
be a model/policy agnostic scheme for generating attestations on the
state of the platform at large or a workload.  Workload models are
supported by a concept known as a security modeling namespace, much
like any other namespace, that tracks events for an isolated process
heirarchy.

The most important review comment on the V1 patchset, that can also be
found on lore, was by Greg Kroah-Hartmann who suggested using a
standardized encoding scheme like JSON for the event descriptions.  If
you look at his comments, he indicated that there is little rationale
for not using an encoding format that the entire technology industry
trusts and uses.

FWIW, we made the change to JSON and have never looked back, it was
the most positive review comment we received.

The current format would not seem to have any issues supporting IMA
style attestation.  For example, the most important event for IMA
would be a file open event.  Here is an example of the encoding
generated for that event:

{
    "event": {
        "process": "quixote",
        "type": "file_open",
        "ttd": "219",
        "p_ttd": "219",
        "task_id": "20e07b3614ee37869391849278dfe7285f37ec2362f7d10c052e6715ad888584",
        "p_task_id": "20e07b3614ee37869391849278dfe7285f37ec2362f7d10c052e6715ad888584",
        "ts": "6535350020298"
    },
    "COE": {
        "uid": "0",
        "euid": "0",
        "suid": "0",
        "gid": "0",
        "egid": "0",
        "sgid": "0",
        "fsuid": "0",
        "fsgid": "0",
        "capeff": "0x3ffffffffff"
    },
    "file_open": {
        "file": {
            "flags": "32800",
            "inode": {
                "uid": "50",
                "gid": "50",
                "mode": "0100755",
                "s_magic": "0xef53",
                "s_id": "xvda",
                "s_uuid": "feadbeaffeadbeaffeadbeaffeadbeaf"
            },
            "path": {
                "dev": {
                    "major": "202",
                    "minor": "0"
                },
                "pathname": "/opt/Quixote/sbin/runc"
            },
            "digest": "81f73a59be3d122ab484d7dfe9ddc81030f595cc59968f61c113a9a38a2c113a"
        }
    }
}

There is sufficient information included to track the digests of
executable files, or any other type of file for that matter, for any
user on the system.

This isn't an attempt to pitch TSEM, but rather to suggest the utility
of a self-describing JSON format for security logging.

As GKH correctly noted in his review comments, there is a great deal
of utility to be had by using a format that has significant and mature
userspace tooling support.  Our own work and deployments have also
indicated a great deal of utility to having log entries that are
self-describing.

One additional observation that may be of use with respect to anyone
pursueing an alternate event log format has come out of our data
science team.  They indicate there has been significant work in the
Elastic search community with respect to the development of
standardized descriptions of events for logging and other purposes,
reference the following URL:

https://www.elastic.co/guide/en/ecs/current/index.html

Our data team is looking at modifying our current security event
descriptions to be as consistent as possible with existing standards
for identifying event parameters.  Given that attestation and host
based security event modeling are only going to become more important
in the future, there would seem to be utility in working towards
contributing to standardized descriptions for security relevant logs.

Hopefully the above reflections are of assistance in furthering the
various agendas that are involved.

Have a good remainder of the week.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
              https://github.com/Quixote-Project