Suppose there is a web application under public load that runs under a very restrictive MAC (e.g., SELinux, TOMOYO, Grsecurity) policy. Suppose we detect and log a MAC policy violation like a file being read or written by the web application that shouldn't be.

Can this MAC policy violation be tracked back to a HTTP request that caused it? How?

Web application is under load of more than 100 requests/s. All requests are legitimate, except one, which is malicious. The malicious request needs to be found so it can be analysed to determine how it passed the security filter inside the application.

1 Answer 1


In very general terms, your problem is one of keeping context information. IF we assume the following:

  • Each request is handled by some code in the server, with one of the execution threads.
  • Each thread processes one request at a time.
  • The server code logs each incoming request with both a high-precision time stamp (milliseconds or below) and the identifier for the handling thread.
  • The MAC policy engine, when it detects a violation, logs it along with a high precision time stamp and context information, in particular the identifier for the offending thread.

Then it becomes easy to map violations onto requests.

In practice, depending on the involved technology (server code, application design, policy engine...), some of the above information may be missing. For instance, the policy engine may log only the process ID and a process may contain several threads (there are "system threads" handled by the OS, but at application level there can also be so-called "lightweight threads" that the OS is not aware of). Some server engines may pursue several requests simultaneously (state machine design with poll()). Logs may lack sub-second precision. In the server, the I/O accesses may be centralized and shared, so the thread which received the request is not necessarily the one which does the file access.

If you do not have all the needed information, then you will have to analyse all the requests received in the relevant time frame, until you find the funky one. You might want to resort to simulation: keep all incoming requests in a circular buffer, so that at any time you have a copy of the last minute worth of request data or so; if the policy engine detects a violation, make a snapshot (a copy of the requests and the relevant server state). Afterwards, during analysis, resubmit all these requests to a copy of the server, one at a time, until you find the one which triggers the problem.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.