Jesse Pollard <pollardat_private> wrote: > --------- Received message begins Here --------- >> >> Jesse Pollard wrote: >> >have to mediate mmap too. >> >> Why? In Janus, we pushed all these checks to open(). >> [For instance, mmap() won't lead you write to a file opened read-only.] >> >> Probably I'm overlooking something. I'd love to be enlightened. > A file may have its permissions changed to deny the process access. In the > current method, access is only checked on open. So once a process does a > fork+exec (optionally with setuid..) access to the given file should no > longer be allowed. > close the relevant files before fork, but that is not always possible > due to bugs (buffer overflow/worm attack). If the parent process is malicious then it doesn't matter if the child it creates is running in a more restrictive protection domain or not, the parent still has access to the sensitive capabilities. In short if evil process A passes a descriptor to evil Process B it is no worse just having that descriptor in the hands of evil process A. If you want to force a parent application (say a webserver) to start a child application (say a CGI script) in a restricted subdomain you can always force it to go through a trusted wrapper program that does revocation. For example, suexec (the apache exec wrapper) could trivially be hacked to clean up the descriptor space before starting new child processes. > This is why read/write needs > to be monitored, and since mmap can accomplish the equivalent I/O it too > should be monitored. This is not the only answer. You can accomplish the same thing by supporting revocation of descriptors (not an especially hard change) and thus retaining all the benefits of the capability model provided by descriptors. --Tal _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Fri Apr 27 2001 - 11:56:30 PDT