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@xxxxxxxxxxxxx> Reply-To: dev@xxxxxxxxxxxxxxxx To: dev@xxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxx> -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@xxxxxxxxxxxxx> -- 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.
