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
