On Sun, Sep 26, 2010 at 1:15 PM, Tetsuo Handa <from-****@i-lov*****> wrote: > (I modified subject line in order to split this thread into "mprotect restriction" > part and "simple GUI for learning mode" part. This is the "mprotect restriction" part.) > > Radoslaw Szkodzinski wrote: >> On Sun, Sep 26, 2010 at 7:46 AM, Tetsuo Handa >> <from-****@i-lov*****> wrote: >> > >> > Radoslaw Szkodzinski wrote: >> > > 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. >> > >> > It will be possible to reject A-2 and B-2 below >> > >> > (Step A-1) Create a vma as PROT_WRITE . >> > (Step A-2) Change that vma to PROT_EXECUTE . >> > >> > (Step B-1) Create a vma as PROT_EXECUTE . >> > (Step B-2) Change that vma to PROT_WRITE . >> > >> > by doing >> > >> >> Do not touch vm_flags directly. grSecurity does that, because it's not >> an LSM hook... > > I don't modify vm_flags. I modify only vm_flags_ever_specified. > What does "touch vm_flags" mean? > Do you mean not only "modifying vm_flags" but also "reading vm_flags"? I think that's why reqprot and prot are there, otherwise prot sounds redundant. Of course, better ask LSM lawyers. ;) >> Fixed: >> if ((reqprot & (VM_MAYWRITE | VM_MAYEXEC)) ^ (prot & (VM_MAYWRITE | >> VM_MAYEXEC))) && >> > ? ? ?!ccs_capable(CCS_USE_WRITABLE_EXECUTABLE_VMA)) >> > ? ?return -EPERM; >> >> (or possibly with the check of vma->vm_flags_ever_specified like that below ;) ) >> > I think vma->vm_flags_ever_specified is needed in order to handle C-3 . Yes, it is. >> This means that pages already marked write and executable would stay >> that way and not throw -EPERM >> when being marked VM_MAYREAD. >> > Why not to throw -EPERM? The idea is that the page already was VM_MAYEXEC|VM_MAYWRITE, so something has allowed it before, and now the code might want to do VM_MAYREAD|VM_MAYEXEC|VM_MAYWRITE, a full set of rights. >> > Also, I think >> > >> > (Step D-1) Create a vma as PROT_WRITE|PROT_EXECUTE . >> > >> > is possible by using mmap(). > <snipped> > > Therefore, I think that checking VM_MAYWRITE | VM_MAYEXEC inside > existing security_file_mmap() can cover D-1. Yes, it's enough. > After all, what I need to do are add > > unsigned long vm_flags_ever_specified; > > to "struct vm_area_struct" and do > > if ((prot << 4) & (VM_MAYWRITE | VM_MAYEXEC)) == (VM_MAYWRITE | VM_MAYEXEC) && This works for security_file_mmap. > !ccs_capable(CCS_USE_WRITABLE_EXECUTABLE_VMA)) > return -EPERM; > > inside security_file_mmap(file, reqprot, prot, flags, addr, addr_only) and do > > vma->vm_flags_ever_specified |= vma->vm_flags; > if (((vma->vm_flags_ever_specified | (prot << 4)) & > (VM_MAYWRITE | VM_MAYEXEC)) == (VM_MAYWRITE | VM_MAYEXEC) && This maybe could break, because it blocks VM_MAYWRITE|VM_MAYEXEC -> either or nothing, that is, reducing the permission. The trick is of course that it needs > !ccs_capable(CCS_USE_WRITABLE_EXECUTABLE_VMA)) before even getting VM_MAYWRITE|VM_MAYEXEC... The only possibility I can see is someone enabling TOMOYO while apps are already running and have some VM_MAYWRITE|VM_MAYEXEC and happen to want to drop that. Fairly small chance, but there. Slightly modifying the test fixes this slim chance. >> No, PAX_MPROTECT alone isn't arch-dependent, rest of the PaX is. >> CONFIG_PAX_MPROTECT touches two files, fs/binfmt_elf.c >> (to check its enable/disable flag) and mm/mprotect.c. > > config PAX_MPROTECT depends on (PAX_PAGEEXEC || PAX_SEGMEXEC) and > config PAX_PAGEEXEC depends on !COMPAT_VDSO && PAX_NOEXEC && (!X86_32 || M586 || M586TSC || M586MMX || M686 || MPENTIUMII || MPENTIUMIII || MPENTIUMM || MCORE2 || MPENTIUM4 || MPSC || MATOM || MK7 || MK8 || MWINCHIPC6 || MWINCHIP2 || MWINCHIP3D || MVIAC3_2 || MVIAC7) and > config PAX_SEGMEXEC depends on !COMPAT_VDSO && PAX_NOEXEC && X86_32 . Yes, because mprotect protection is much less useful without mmap randomization. (as without that, you could just overwrite that mmap using some buffer overflow) What you didn't check is that mmap randomization is in mainline as well now. :) So this is just PaX developer covering all bases. > It seems to me that I can't clone code from PAX_MPROTECT without limiting archs. Of course you can. Again, CONFIG_PAX_MPROTECT alone touches mmap and mprotect only. The other two *were once* necessary to make sure the mmap address is randomized. As it is today, that dependency isn't strictly necessary. Also, PaX devs like to promote their own ASLR, which is slightly better on x86 without NX bit. >> > TOMOYO simply validates arguments passed to syscalls. TOMOYO does not track >> > owner of objects. TOMOYO tracks only subjects using domainnames >> > (e.g. <kernel> /usr/sbin/httpd ). I think CONFIG_MM_OWNER=n is not a problem. >> >> But the security_file_mprotect hook doesn't have a "domain" argument >> or anything linking the mapping directly to the task, neither does >> vm_addr_struct. >> How can you get domain info without the domain name? :) >> > I couldn't understand it. > What TOMOYO will control is whether current thread is allowed to specify And you know it's current, so you can just use current task global variable. :blushes: > > PROT_WRITE|PROTO_EXEC when creating a VMA using mmap() syscall Trivial, doesn't need history. > > PROT_WRITE when modifying an existing VMA which ever had PROT_EXEC in the past > using mprotect() syscall > > PROT_EXEC when modifying an existing VMA which ever had PROT_WRITE in the past > using mprotect() syscall These two need that history flag. This might be trickier to get past mainline developers, as that's extra byte (or more) per page. 1 MB of kernel memory (lowmem, which is typically 768 MB) for every 4 GB in addition to slowing down mmap slightly. This could theoretically bite on 32-bit PAE with large amounts of RAM (like 64 GB, which is the maximum, there it eats 16 MB which might be enough for the kernel to run out of lowmem in some workloads). Of course, it could be argued those people should switch to 64-bit or use something else than TOMOYO. > TOMOYO doesn't care who owns a VMA (as with who created a file, > whereas inode-based security cares it by allocating memory and using xattr on > filesystems). > TOMOYO's domainname is derived from "struct task_struct"->ccs_domain_info . :blush: This means current->ccs_domain_info of course.
TOMOYO
Fork