Hi all,

I have a question that touches on the security of a new tool I am
thinking of writing. In order to understand the threats, I need to know
the following. Supposing I have a process that does the following:

   * Create a temporary file and open it read-only.
   * Map that file into memory (using mmap in share mode) with a
     read-only protection.
   * Close the file descriptor
   * Unlink the original file


After these operations, the process can change the memory content by
calling mprotect to turn the mapping into read-write, and then write
there. Assuming that particular avenue is blocked from it (i.e. - there
is an external program that monitors attempts to use mprotect over that
particular piece of memory and blocks it), what other avenues are
available to it?

In particular:

   * Can it reopen the file somehow? I know it does not appear in
     /proc/pid/fd (as there are no file descriptors pointing to it any
     more)
   * Can it get a second mapping of the file, somehow? In particular,
     through /proc/pid/mem (obviously, the answer is "yes")? Can that
     second mapping be turned into read-write? If so, will writing to
     the second mapping affect the memory image appearing in the first one?
   * Is there another syscall, besides mprotect, that may change the
     mapping to writable?
   * Does it matter if the original fd was opened in read-write or read
     only mode? WIll opening it read only prevent writing to the mapped
     memory?

The tool itself is meant to be based on the fakeroot-ng technology. It
will jail untrusted programs (think - skype) inside a directory, only
allowing it access outside this directory for predefined resources. This
means it's much easier to set up a jail than a chroot, because you don't
need root permissions, you do not need to fill in the directory with all
of the required libraries (just allow it to access the original
libraries), and since it does not run as root, it cannot escape.

Doing this is almost meaningless, however, unless I manage to make sure
it absolutely cannot bypass the altered syscalls I impose on it. I think
I found a way involving shared memory which is mapped read only inside
the jailed process, but I would like to make sure that this is, indeed,
the case.

Thanks,
Shachar


=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]

Reply via email to