Re: [PATCH] permission hook in filemap_nopage

Previous message: Stephen Smalley: "Re: [PATCH] permission hook in filemap_nopage"
Maybe in reply to: Antony Edwards: "[PATCH] permission hook in filemap_nopage"
Next in thread: Antony Edwards: "Re: [PATCH] permission hook in filemap_nopage"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

aedwardat_private

> Given 2 processes that both open a file 'foo', and then use that fd to
> open an MMAP_SHARED, what happens if one process gets the fd revoked?

AFAIK - (assume process-A has the fd revoke and process-B doesn't). Any
data B writes into the buffer will automatically be viewable by A.
Furthermore - if new sensitive data is added to the file that A shouldn't
see, as long as B faults on the page first -- A will be able to get access
to the page without going through filemap_nopage.

The second behaviour could be stopped by putting the hook in
handle_pte_fault instead of filemap_nopage. The first behaviour cannot be
prevented with a hook -- the module would have to go and remove the PTEs.
My reasoning for putting the hook in filemap_nopage was:

(1) Performance. filemap_nopage means we are going to disk (maybe we are
    going to some other device or even /proc -- but disks are the common
    case) -- therefore -- an extra check shouldn't really hurt performance.

(2) These problems are introduced because MMAP_SHARED combines file I/O
    with shared memory. I only wanted to make the file IO checks
consistent.

> (For that matter, in the I-havent-tried category, if you mmap() and then
> close() that fd, does the mmap() persist and Do What You Expect?) The
other
> process could then still "tunnel" information out.

The vm_area -> file mapping stays until you have munmaped the file.

Antony