TEH JIA YEW wrote: > 4. I am planning to use IMA to create a clean database of SHA1s from " cat > /sys/kernel/security/ima/ascii_runtime_measurements". The clean database of > SHA1s will be compared to runtime database of SHA1s also from " cat > /sys/kernel/security/ima/ascii_runtime_measurements". If any SHA1s changed, > alert will be raised and any read or write access to critical kernel files > will be denied. > > I plan to use Tomoyo 1.8.3 to perform the denial of read or write access to > critical kernel files I think MAC may not be the best tool for doing that. Generally, MAC is used for denying unwanted access from the beginning. If MAC is used, the MAC policy should deny read/write access to critical kernel files from the beginning (except that some special domains that need to read/write such files, for example rpm and dpkg applications) rather than not denying read/write access to critical kernel files until something bad begins. > 6. Can Tomoyo 1.8.3 be used to disallow read& write access to kernel files > and any files in the "/ " filesystem? TOMOYO is not suitable for doing that. And I think other MAC implementations may not be suitable due to usage of MAC described above. > 9. Now, in reference to my plans in no.4 above, would it be possible if I > have a domain that consists of ALL kernel files, and when SHA1s of files > differs, have a TOMOYO policy disallow read/write access to ALL kernel files > in the my domain? Why disallow from only specific domain? If other domains are not disallowed from reading/writing, bad thing will go on. Also, if SHA1 mismatch is triggered by directly writing to device files (e.g. "cat /dev/zero > /dev/sda"), can we protect something by disallowing read/write access to ALL kernel files? > 10.What I mean is that can Tomoyo work based on a domain of files instead of > domain of applications or binaries or services as per > "http://tomoyo.sourceforge.jp/1.8/chapter-5.html.en"? Currently not. If "read or write access" implies permission checks upon each read()/write() request, permanently not. (Calculating and comparing pathnames on each read()/write() request is too slow to do.) For implementation, how do you define "ALL kernel files"? By pathnames (e.g. /lib/modules and /boot ) or by inodes (e.g. inode's number or xattr information (so called "label") associated with inode)? If by inodes, SELinux or SMACK will be better choice. Since requirement/specification is too obscure to suggest which tool is the most suitable for you, so far a kernel module to "trigger kernel panic upon SHA1 mismatch" sounds the best tool.
TOMOYO
Fork