On 4/3/19 7:57 AM, Mimi Zohar wrote:
On Fri, 2019-03-29 at 15:50 +0300, Igor Zhbanov wrote:
On 29.03.2019 15:28, Stephen Smalley wrote:
On 3/29/19 6:59 AM, Mimi Zohar wrote:
[Cc'ing the LSM mailing list and others]
On Fri, 2019-03-29 at 13:00 +0300, Igor Zhbanov wrote:
Hi Mimi,On 28.03.2019 20:17, Mimi Zohar wrote:
I just came across the grsecurity article on mprotect.[1]
Has anyone looked at it? Would it make sense to make it a minor LSM?
[1]https://pax.grsecurity.net/docs/mprotect.txt
Interesting article. It is almost exactly of what I wanted to be
implemented.
If this minor LSM would be stackable to allow combining with e.g. SELinux
then why not.
Stacking shouldn't be a problem. Other LSMs are already on the
mprotect hook. Let's hear what others think.
SELinux already provides a set of controls over executable mappings;
see selinux_mmap_file and selinux_file_mprotect. Other major security
modules may do likewise but I can't speak to that. Is there some gap
you are trying to address that isn't already covered, or are you just
trying to provide such restrictions without requiring one of the
major modules?
I want to be sure that no unsigned code page could be executed. So exploits
could only be of ROP kind and not being able to download any extra code
from their servers. That's why I found that disabling of anonymous executable
pages could be useful for that (as well as disabling of making executable
pages writable to modify already mapped code). In conjunction with IMA it
should guarantee that no untrusted code could be executed.
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.
