On Wed, 2019-04-03 at 10:33 -0400, Stephen Smalley wrote: > On 4/3/19 10:33 AM, Mimi Zohar wrote: > > On Wed, 2019-04-03 at 09:10 -0400, Stephen Smalley wrote: > >> On 4/3/19 7:57 AM, Mimi Zohar wrote: > > > >>> Let's separate the different types of attacks. From an IMA > >>> perspective, memory attacks are out of scope. That leaves mmap'ed > >>> files, possibly just mmap'ed shared files. Currently IMA can be > >>> configured to verify a file's integrity, based on signatures, being > >>> mmap'ed execute. Assuming that not all files opened require a file > >>> signature, a file could be mmap'ed read/write and later changed to > >>> execute to circumvent the mmap'ed execute signature requirement. If > >>> the existing LSMs are able to prevent this sort of attack, we could > >>> just document this requirement. > >> > >> I guess I don't understand why IMA isn't already being called from > >> security_file_mprotect(). security_file_mprotect() could just call > >> ima_file_mmap(vma->vm_file, prot) if all of the security hooks pass. > >> > >> SELinux can be used to prevent unauthorized mprotect PROT_EXEC but it > >> won't perform a measurement of the file if it is allowed by policy. > > > > From a measurement perspective, this will at least measure the file, > > but the call to ima_file_mmap() will verify the file signature against > > the file, not what is currently in memory, right? > > Yes, but you can use SELinux to prevent that (don't allow execmem or > execmod permissions for that domain). Ok, let's start with at least adding the ima_file_mmap() call as you suggested. For LSMs which don't have this capability, they might need to be stacked with a minor LSM such as S.A.R.A, once it is upstreamed, or similar. Mimi
