Multithreaded applications, SELinux, and RAM Protection

Multithreaded applications, SELinux, and RAM Protection

[Shawn Wells]

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.

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!
   

-- 
Shawn D. Wells
Solutions Architect, Federal Team


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [gov-eng] Multithreaded applications, SELinux, and RAM Protection

[Shawn Wells]

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [gov-eng] Multithreaded applications, SELinux, and RAM Protection

[Stephen Smalley]

On Thu, 2008-02-07 at 00:38 -0500, Shawn Wells wrote:
> 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)

setcon() presently fails with EPERM if a multi-threaded application
tries to invoke it.

You can't prevent a thread within a process (thread group) from
accessing any of the memory - they share the same memory space.  Thus,
you can't safely run one thread in one security context and another
thread in another security context.

As your colleague suggested, use separate processes instead.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.