Re: /dev/random MLS policy

[Matthew Sheets <masheets@linux.microsoft.com>]

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