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
if (((vma->vm_flags | (prot << 4)) &
(VM_MAYWRITE | VM_MAYEXEC)) == (VM_MAYWRITE | VM_MAYEXEC) &&
!ccs_capable(CCS_USE_WRITABLE_EXECUTABLE_VMA))
return -EPERM;
inside security_file_mprotect(vma, reqprot, prot).
But it is impossible to reject C-3 below
(Step C-1) Create a vma as PROT_WRITE .
(Step C-2) Change that vma to PROT_READ .
(Step C-3) Change that vma to PROT_READ|PROT_EXECUTE .
unless "struct vm_area_struct" has a variable which remembers the bitwise OR of
PROT_* flags ever specified since the moment a vma was created. I need to add
unsigned long vm_flags_ever_specified;
to "struct vm_area_struct" 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) &&
!ccs_capable(CCS_USE_WRITABLE_EXECUTABLE_VMA))
return -EPERM;
inside security_file_mprotect(vma, reqprot, prot).
Also, I think
(Step D-1) Create a vma as PROT_WRITE|PROT_EXECUTE .
is possible by using mmap().
If D-1 is possible, checking it at security_file_mprotect() is not sufficient.
What do you think?
> 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.
TOMOYO touches only arch independent part.
CONFIG_PAX_MPROTECT is arch dependent and too complicated for me.
(You can enable PaX and TOMOYO at the same time if you want to do so.)
> 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.
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.
> > Any questions so far?
>
> No, this description is excellent for what I need.
I see. A few remaining notes.
Only programs (or domainnames) specified in /proc/ccs/manager can modify policy
via /proc/ccs/ interface. You will need to either
add the pathname of your program to /etc/ccs/manager.conf so that
/sbin/ccs-init will load /etc/ccs/manager.conf to /proc/ccs/manager
or
add the pathname of your program to /proc/ccs/manager using
"echo /path/to/your/program | /usr/sbin/ccs-loadpolicy -m"
.
/usr/sbin/ccs-queryd (for TOMOYO 1.7) creates a child process which monitors
changes in /etc/ld.so.cache and reflect changes to /proc/ccs/exception_policy
as "allow_read /path/to/shared_library_files_without_wildcards".
This child process does not use /proc/ccs/query interface in order to avoid
keepalive problem.
This child process (and /usr/sbin/ccs-ld-watch) will be gone in TOMOYO 1.8
because I changed to use "file read
/path/to/shared_library_files_with_wildcards".
Please be sure to call fflush() after writing a line (or use line buffering
mode)
if your appliocation's write method does not call write() syscall.
I tried to let /usr/sbin/ccs-queryd search a database and reply if $retry is 0
and let /usr/sbin/ccs-queryd ask the user what to do if $retry is not 0. But I
haven't implemented it yet and therefore some dead code exists in queryd.c .
You can just ignore it.
/usr/sbin/ccs-queryd supports monitoring remote machines (e.g. embedded devices
running on emulator). ccs-editpolicy-agent can be used for waiting for TCP
connections from ccs-loadpolicy/ccs-editpolicy/ccs-savepolicy/ccs-queryd etc.
on remote machines. Its communication protocol is very simple.
ccs-editpolicy-agent will read the file until EOF and sends to remote host
if a received byte is '\0', The EOF is indicated by '\0'.
ccs-editpolicy-agent will write that byte to the file if a received byte is not
'\0'.
I think you don't need to implement this feature for now.
Those who can use emulator know how to use CUI.
Regards.
_______________________________________________
tomoyo-users-en mailing list
[email protected]
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en
