On Fri, May 12, 2017 at 12:30 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > On Fri, 2017-05-05 at 09:14 -0400, Stephen Smalley wrote: >> Add a map permission check on mmap so that we can distinguish memory >> mapped >> access (since it has different implications for revocation). When a >> file >> is opened and then read or written via syscalls like >> read(2)/write(2), >> we revalidate access on each read/write operation via >> selinux_file_permission() and therefore can revoke access if the >> process context, the file context, or the policy changes in such a >> manner that access is no longer allowed. When a file is opened and >> then >> memory mapped via mmap(2) and then subsequently read or written >> directly >> in memory, we presently have no way to revalidate or revoke access. >> The purpose of a separate map permission check on mmap(2) is to >> permit >> policy to prohibit memory mapping of specific files for which we need >> to ensure that every access is revalidated, particularly useful for >> scenarios where we expect the file to be relabeled at runtime in >> order >> to reflect state changes (e.g. cross-domain solution, assured >> pipeline >> without data copying). >> >> Signed-off-by: Stephen Smalley <sds@xxxxxxxxxxxxx> > > Unless you have any comments/objections, feel free to apply this as is > - I believe it is good to go, and I have also posted the corresponding > selinux-testsuite patch. No objections and I think the only comments I had were covered in the policy capabilities thread (I agree that we should let handle_unknown take care of things in this patch). Looks good to me, merged. -- paul moore www.paul-moore.com
