[Fwd: [idea] web-application security powered by SELinux]

[KaiGai Kohei <kaigai@ak.jp.nec.com>]

FYI,

I posted a message to open discussion for SELinux support on apache/httpd.
If you like to join the topic, please subscribe the "http-dev" list here.

  http://httpd.apache.org/lists.html#http-dev

-------- Original Message --------
Subject: [idea] web-application security powered by SELinux
Date: Wed, 25 Mar 2009 09:55:06 +0900
From: KaiGai Kohei <kaigai@ak.jp.nec.com>
Reply-To: dev@httpd.apache.org
To: dev@httpd.apache.org

Hello,

Now I have considered the way to work web-applications with restrictive
privileges set based on an identification of the client. It enables to
check and prevent violated actions from (buggy) applications using
features provided by the operating system.

I'm concerned about most of web-application, such as PHP scripts, are
launched as part of web-server process itself. It also means all the
web-application instances share the same privilege set of the server
process, even if these are invoked on the requests come from different
users. In other word, we cannot apply valid access controls on them
(except for ones applied by web-application itself, but it is hard to
ensure they don't have security bugs), because it seems to the operating
system multiple processes/threads with same privileges run simultaneously.

If we can run web-applications with more restrictive privileges set
for each users, groups and so on, the operating system can acquire
any actions from userspace and apply its access control policies.
I assume SELinux as the operating system feature here, but not
limited to SELinux. I guess this discussion can be applied on any
other advanced security features also.

In my opinion, we need the following three facilities:

1. The backend identifies the client and decide what privileges should
   be assigned on the launched web-applications prior to its invocation.
   The existing http-authentication is a candidate, but we don't assume
   a certain method to identify the client.

2. The backend creates a one-time thread or process to handle the given
   requests, and assigns the new privileges, then launches the worker
   thread or process to invoke contents handler.

3. The backend wait for the completion of the worker. The reason why
   we don't use them again is that it is fundamentally danger to allow
   a path to revert the privileges of web-application.

Please note that we don't assume users who want to use this feature
give first priority for performance. It is a kind of security tradeoff.

One idea is to add a security focused MPM which provide above features
and hooks for external modules.
I've actually developed a working example based on the "prefork" MPM.
When it accepts a request from the client, it creates a one-time thread
and assigns a new security context (which is a privileges set in SELinux),
then invokes contents handler.

  http://code.google.com/p/sepgsql/source/browse/misc/httpd-selinux/

However, I don't adhere the current implementation as is.
I would like to have a discussion to brush up the idea to achieve
the goal and to get acceptance in the mainline.

Any comments, questions and others are welcome.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
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.