does fapolicyd support caching file hash in the extended attributes?

[t57root]

According to the doc, when using file hash for integrity check fapolicyd could use the hash value in xattr stored by IMA, or calculate hash on-the-fly if it's not already in the cache. Is there an option to cache the hash in xattr like IMA? Thanks

[radosroka]

No it doesn't support. How would you use such feature?

[t57root]

No it doesn't support. How would you use such feature?

I'm thinking if the hashes are stored in xattr, then the cached values would not be "evicted" and be avaliable all the time (comparing with LRU cache). We can also record the timestamp when the hash are calculated and re-calculate it when the mtime changed.

[radosroka]

You want fapolicyd to compute all the hashes an to put them into xattrs and to keep them up to date or just let fapolicyd to consume hashes from given xattr? and let some other application to update hashes?

[t57root]

You want fapolicyd to compute all the hashes an to put them into xattrs and to keep them up to date or just let fapolicyd to consume hashes from given xattr? and let some other application to update hashes?

I want fapolicyd to compute all the hashes an to put them into xattrs and to keep them up to date. According to my understanding, the second option is exactly what IMA's doing.

[radosroka]

If you don't want IMA then why not to use sha256 instead?

[t57root]

If you don't want IMA then why not to use sha256 instead?

If using sha256 without IMA, the doc says, If this is set to sha256, then every miss in the object cache will cause a hash to be calculated on the file being accessed. If fapolicyd store the hash into xattr, then there'll be no more cache miss.

[radosroka]

If you don't want IMA then why not to use sha256 instead?

If using sha256 without IMA, the doc says, If this is set to sha256, then every miss in the object cache will cause a hash to be calculated on the file being accessed. If fapolicyd store the hash into xattr, then there'll be no more cache miss.

You can definitely play with a cache size...

[stevegrubb]

As I understand it, you would prefer to have fapolicyd to write the hashes to xattrs so that it can later save time by not calculating hashes when they get evicted - but rather read them from disk. We have benchmarked fapolicyd alot. The two time sinks is the sha256 hash and the magic lookup. The size of the file in question will have an effect on how long it takes to hash. Reading the xattr could take longer for small files.

IMA has 2 modes, ima_appraise = fix and ima_appraise = enforce. If you leave IMA in the fix mode, any update you do to a file will also update the hash that IMA has. Fapolicyd can just use that so that it doesn't have to write to the file system. (This might be the best option, let IMA make the hashes but don't use it for enforcement.) Right now, fapolicyd does not alter any system attributes as it runs. Kind of hate to get into that business as it will literally be any file accessed. With systems that have big disks, you get big inodes. So, I'd rather not be the culprit that used up a lot of disk space.

Also, fapolicyd would have to write user extended attributes and there wouldn't be any security to them. Anyone with write access to the file can alter them to match the file.

[sopos]

The last paragraph is crucial here, I guess. If it was written to the xattr we couldn't be sure if it is still authoritative.

[stevegrubb]

I think this can be closed. It was an interesting idea, but I think we are not going to cache in xattrs. If there is anything else to discuss, feel free to reopen.