Log Analysis and Trust Designator

[dorschs57]

When calculating the Trust column in the log file Analyzer Tool the prototype document gives the following description:

However with the current system we don't have enough data to determine the ST value in those 2 cases. In both cases the subjects trust value would be "AT". In the first case it's trust status would be "T" and in the second it would be "D". Want we can't tell is it's trust and status on the system trust database, it's "secondary" trust. Should we:

1. add properties to pass the data about the "secondary" trust, in this case the ST trust or
2. maybe the "secondary" trust doesn't matter so we just always level it normal font and black text.

There is also the inverse case to this one where the file would be trusted in the system trust database and appears in the ancillary trust database. In this case the "secondary" trust would be the AT value which currently couldn't be determined.

[jw3]

Just talking through this with some background info that may be common knowledge already, but I put it here for posterity in case its not common, and to make me think.

We use the fapolicyd trust database (lmdb) as the sole source of trust for the initial system. The lmdb store is a KV mapping of path to trust data, which only allows a single entry per path. What we call the system trust is populated by the RPM DB by the fapolicyd daemon. The init process for the trust database is a one time dump of all applicable entries from the RPM DB to the lmdb backend, after that is done the ancillary trust is ingested, overwriting any matching entries from the system trust. So, as a result there is no secondary trust in the fapolicyd trust db, there is only trusted or not.

It would be possible to go back and get an indication of the system trusted status from the RPM DB. The file on disk would have to be stat'd and have it's hash checked. Probably would be best to have a lazy cache of these values, only doing the check when they are actually needed. They are only needed for a path that exists in the ancillary and has a non-matching hash.

I think that's how it goes. Will have to look at the code to see how it fits.