> The mmap and mprotect calls are already hooked, so you can check the > protection values during those calls. I added the hook to mmap page faults to make the checks performed for file access via mmap consistent as for via open/read/write. I think that adding a hook to sys_read is giving module writers a false sense of security if the application can circumvent this check by mmaping the file. > If you are worried about revoking access after the mmap/mprotect call, then > simply hooking filemap_nopage doesn't solve the problem, since you would > still need a mechanism for revoking pages that have already been mapped. I don't agree. Pages that are already mapped contain data that was read when the application still had permission to the file. It's basically just buffering. The application can't get access to new data from the disk without going through filemap_nopage. Saying that the module has to revoke all pages containing data from the file from the page table is equivalent to saying that the module has to go and clear any user buffers that were passed to read(2). Comments? MMAP_SHARED obviously changes this -- but to me the new aspects are shared memory semantics, and the existing protection is the same as that for normal shared memory. > So it isn't clear that hooking filemap_nopage is worthwhile (although > we did insert a check into it in the original SELinux kernel patch). Agreed. But I do think that the permission hooks in sys_read/sys_write are useless without an equivalent hook in the page fault. Antony _______________________________________________ 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 : Tue Feb 05 2002 - 11:02:14 PST