On Tue, 7 Oct 2014, Josh Stone wrote:
I've been thinking about improving the selinux story -- right now we
must allow execmem/execstack because of the RWX memory maps. I'd like
to try separating this into proper code (R-X) and data (RW-) maps for
inferior allocs. The API appears to already allow requests to specify
what they need, but I worry a little that someone might be lazily making
requests under the assumption that they'll get RWX. Thoughts?
Off the top of my head, I don't think you'll see problems with Dyninst
users making assumptions about having RWX memory. The DyninstAPI
interface is high-level enough that users can't specify their own memory
permissions nor treat data as code. I can't easily picture out how users
could write DyninstAPI code that'd be sensitive to this off the top of my
head.
But anyone who uses the PatchAPI interface to specify instrumentation
could conceivably intermix their data/code. Though I don't think there's
a lot of users in this situation. I use PatchAPI in one of my tools, but
it wouldn't be sensitive to these changes.
A larger problem might be in the binary rewriter. In the ideal case
DyninstAPI appends new program headers to the binary that contain the new
code/data. But there were numerous limitations and bugs across
OSs/Loaders/libelf that limited this ability. As work-arounds Dyninst
situationally adds code ahead of the binary, reuses existing program
headers, and other assorted hacks (see some comments in
symtabAPI/src/emitElf-64.C). Some of these hacks may be incompatible with
making two new program headers. You may have to situationally turn off
seperate RX and RW maps in these cases.
-Matt
|
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}