Your plan would get things working but will be the equivalent of just
making random_device_t an mls trusted object, since everything will
always dominate system low and everything will always be dominated by
system high.
This would make (( t2 == mlsfilewriteinrange ) and ( l1 dom l2 ) and (
h1 domby h2 )) always true. And for read options ( l1 dom l2 ) will be
true for the same reasons.
So path of least resistance you can just make random_device_t
mlstrustedobject.
But you may just be able to deny and dontaudit that access. Things only
write to /dev/random to add more entropy, and you may be able to live
without that. Also since it seems to be happening on exit it's likely
not to have impact on the actual functionality of the system.
From a more philosophical sense if you allow access like this, it will
appear like a transitive data flow for a static policy analysis. But
realize that the kernel is handling data written to /dev/random
differently to that of a flat file. I cannot write some bytes into
/dev/random and get those bytes out as is. Now with a very complicated
attack you can effect the entropy of /dev/random and cause other
software to behave less random, which is generally bad.
On 9/15/2022 6:35 AM, Ted Toth wrote:
I've started writing some SELinux policy for a java app running on a
system configured with MLS policy. I am seeing 'append' AVCs when a
JVM running at any level above SystemLow accesses /dev/random which is
labeled SystemLow. The AVC appears to cause the JVM to exit. Have
others experienced this and if so how did you deal with it? I
considered making /dev/random SystemLow-SystemHigh and adding
mls_file_write_within_range(random_device_t) to policy but am
concerned about the possibility of using the device as a covert
channel. Thought?
Ted
