>>> FWIW, we run apache 1.3 out of xinetd at multiple contexts using labeled >>> networking. HTTP performance is surprisingly good. HTTPS performance is >>> unacceptable, so we are using an HTTPS reverse proxy in a DMZ for single >>> level network services to the 'enterprise'. >> >> Are you saying that xinetd can launch multiple apache/httpd daemon >> processes >> with individual security context? > > Yes > >> If so, unfortunatelly, it is different from >> what I would like to achieve. :( >> >> I guess the security context of the daemon process is determined prior to >> receiving http-requests come from users, but the security context to be >> assigned on web application depends on the authentication-header within >> the http-request-headers, so we cannot know who connected to on xinetd >> time. > > We are basing the context on the context of the connecting user, > delivered by either netlabel or labeled IPSec. We are not changing > context based on apache user authentication. Understood. >> Or, are we talking about topics in different layer? > > Sounds like it. Just wanted to point out that you might not need to > trust apache to achieve some of your goals. We need to trust the apache/httpd applies its authentication and dropping privileges correctly. However, all the new domain is bounded by httpd_t, so there are no fundamental differences outside of the httpd_t. The purpose of this effort is to associate a concept of web-user and a security context while apache/httpd performs as an agent of the human-user. So, I would like to restrict a part of privileges within a set of them allowed to httpd_t. Thanks, -- 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.
