Ben Woodard wrote:
Shawn Wells wrote:
Hi All,
I have a customer who is encountering the following issue, and
I've been unable to solve it myself.
The scenario:
WebUserX (with TS//SCI//Alpha) sends a query to MACHINE1 which then
parses the query and executes it on a database. For example:
|-- WebUserX Sends Query to Query Engine
|--------> Query Engine creates new thread, parses, sends to database
|--------|--------> Database executes & returns data
|--------|--------|--------> Data is stored in RAM, say the first
512MB of allocatable space
|--------|--------|--------|--------> Data passed back to WebUserX
|--------|--------|--------|--------|--------> Query Engine thread
dies, marks first 512MB of RAM available. Doesn't delete the data in
RAM, but it is now tagged as available.
1st suggestion, don't use threads for the query. The first line of
defense that I would setup is to make sure that each and every query
operates in its own compartmentalized address space. Threads share
address space. Processes do not.
Would it be possible, I'm guessing through setcon(), to have threads
change their context and label the data in RAM? Thus revoking
different/lesser threads from accessing that data later? I'm guessing
not, as I believe setcon would change the label for the process, not the
thread -- is this correct? (the man page leads me to this, but I thought
I'd ask)
Suggestion 2 be very very careful in making distinctions between
address apace and RAM. The operating system manages the RAM and gives
the process address space which might be backed by RAM at any given
point. I believe that if you are more careful about delinitating the
two then this will be a simpler problem for you to solve.
Say a process received a range of address space, which was backed by
RAM, and placed labeled (TS//SCI//Alpha) data into it. Later a process
with a lower label receives the same range of address space. Assuming
there is data with the old label still in that range, will the new
process be able to access the old data?
Any pointers to where I can educate myself about how RAM & process space
is allocated? I've been googling, but anyone have some favorite docs?
WebUserY (with TS//SCI//Bravo) sends a different query to MACHINE1
which then parses the query and executes it on a database. Same
process is followed, however the query engine thread becomes
highjacked (bad SQL, bad coding, whatever).
The customer is considering writing a hook to zero-out the RAM after
the thread dies, but this will be a lengthy process.
With all that said, my question is: how can we make sure that the
thread handling WebUserYs' connection (which is running as
TS//SCI//Bravo) can not see the data in the first 512MB of RAM (which
contains TS//SCI//Alpha)?
Possible ideas, that I just don't know enough about yet:
1) Program maps anonymous memory with mmap with PROT_EXEC. Note that
because anonymous memory is zero'd out by the system it makes not
much sense to not have it writable as well. (stolen from
http://people.redhat.com/~drepper/selinux-mem.html)
I googled "selinux, multithreaded applications," but didn't find to
much. Thanks for any help!
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
