On Sat, Sep 25, 2010 at 9:34 AM, Tetsuo Handa <from-****@i-lov*****> wrote: > Hello. > > Radoslaw Szkodzinski wrote: >> Does it support mprotect writable and executable bit protection like >> SELinux supposedly does? >> This closes the last important hole in mainline Exec Shield >> implementation with NX bit (which is in mainline). >> With Tomoyo (1.7 or even maybe 2.3) one could plug this hole easily, >> whitelisting only problematic applications. > > TOMOYO is not dealing mmap()/mprotect() because I'm not familiar with them. > But I think I can add TOMOYO's hook for dealing sys_mprotect() because > security_file_mprotect() is allowed to sleep. Yes, this should work. > How can I implement mprotect writable and executable bit protection? > I don't know how to implement it. The hook would check the mask of the argument of mprotect, rejecting PROT_EXEC | PROT_WRITE, check whether a formerly PROT_WRITE page is being now mprotect()ed to PROT_EXEC or vice versa. This means the all time state of access bits has to be checked. For the implementation, you could take a look at PaX (grSecurity) mprotect protection, here: http://www.grsecurity.net/~paxguy1/ Look for CONFIG_PAX_MPROTECT. Especially elf_handle_mprotect() in the first file which would become your security_file_mprotect() with minor changes... but the problem is how to match vma to the domain. [File fs/binfmt_elf.c, line 29013 of the 2.6.35.4 patch.] If CONFIG_MM_OWNER is defined (select it in Kconfig), you could use vma->vm_mm->owner to find out which task the mapping belongs to, and then check its domain for the flags. If it's not defined, I'm not sure how to find out who owns the mapping from the hook. > Will you suggest me policy syntax you want to use for mprotect() (e.g. > > allow_capability mprotect-write-execute Like this, but the name would rather be: allow_capability mprotect-writable-executable and possibly allow_capability textrel (a safe default would be deny of both, enabling as necessary) the latter toggling text relocations for given domain. > allow_mprotect 00555000-00570000 r-xp /path/to/file This would be caught on open() of the file (with allow_read/write or allow_execute), so not too useful. Using security_file_mprotect should be easy, check reqprot and prot if they match. It's not a complete protection of course. (note: the actual constant names in the kernel might be different) > <snipped ccs-query protocol description> > There are a few more notes on /proc/ccs/query and /usr/sbin/ccs-queryd . Please put all of that into some Documentation/security/tomoyo-query-protocol.txt. > Any questions so far? No, this description is excellent for what I need. Thank you so much. Radoslaw
TOMOYO
Fork