Re: [PATCH] permission hook in filemap_nopage

From: Valdis.Kletnieksat_private
Date: Tue Feb 05 2002 - 11:39:38 PST

  • Next message: Stephen Smalley: "Re: [PATCH] permission hook in filemap_nopage"

    On Tue, 05 Feb 2002 14:01:06 EST, Antony Edwards <aedwardat_private>  said:
    
    > 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).
    
    Agreed - and of course, the *big* problem is that once filemap_nopage has
    read it in and it's been in the shared memory segment, you have to assume
    it's been copied out of it into some arbitrary userspace databuffer.
    
    > 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.
    
    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?
    (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.
    
    Of course, that's just a specific of the general problem of two processes
    in distinct security domains passing data over a connection (be it TCP,
    a semaphore, unix-domain sockets, a named pipe, or even a shared file..)
    
    /Valdis
    
    
    
    

    _______________________________________________ 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:40:36 PST