httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From KaiGai Kohei <kai...@ak.jp.nec.com>
Subject Higher design of a new web-application security approach
Date Thu, 09 Apr 2009 02:03:40 GMT
Hello,

As we had a short discussion yesterday, we should rewind it to
the higher level viewpoint prior to implementation level.
I described it as follows, but it becomes a bit long sorry.

At the beginning, we can consider this proposition as an analogy
with identification, authentication and privileges on operating
system.

When we want to use an operating system to access files managed
by them, we need to login and operate an agent which can perform
in the system instead of us. If we choose the ssh as a channel
to access a certain file, we need to login the system prior to
any accesses.
The sshd calls its identification and authentication mechanism,
then it forks a process and executes a shell program as an agent
of ours. It also assigns a suitable privileges on the agent to
restrict what it can do in the system. At the last, we send the
agent a few requests to access the target files, such as a command
of "cat /path/to/file". The agent works according to the request
and the operating system checks it based on privileges of the agent
and the attributes of the file.

Meanwhile, if we choose the web-system as a channel to access
a certain file, different entities performs as our agent.
In this scenario, we need to send information of identification,
authentication and request within a single request message,
because it is a state-less system. The web server can apply its
authentication mechanism on the request (if configured) prior to
invocations of contents handler. In the next, the web server itself
performs as our agent. It walks on the list of contents handler and
the first matched one handles the given request.
The invoked handler accesses required files instead of us, but its
privilege is uniform from viewpoint of the operating system, so it
cannot apply appropriate access controls in spite of the agent
which represents various users.

It is a concern for me. The identified username is indeed exposed to
web applications, but each web applications can discretionary use or
unuse it, and we have no assurance its access control is comprehensive.
The best way to acquire and check any request on resources is effective
utilization of operating system, so it is necessary to assign individual
privileges on the context of our agent prior to its invocations.

This design enables to restrict any actions of agents based on the
privileges independently from what handler is invoked. For example,
when a web server publishes several pdf documents but a part of them
labeled as "internal_use" should not be exposed for anonymous, we don't
want to leak them from any channel, even if it is normally specified by
url to the files directly. If a php script has a bug to allow client to
specify discretional file, it may bypass our assumption, but it is not
preferable behavior. If the operating system have performed as the last
wall, we could prevent such kind of inconsistency. (Please note that I
never said application level access controls are not necessary.)

In my proposal, it created a one-time thread to perform as an agent of
user and it executed the required contents handler with restricted
privileges. It assumes that we can trust the modules of script language
as well as the httpd binary, but here is no assurance web-applications
are trusted. Indeed, it may be a bit weaker assumption than CGI separation,
but it is not bad we have several options depending on required security
level and acceptable tradeoff.
In addition, it is not preferable for me to modify existing applications
to make them suitable for the mechanism as far as possible, because
a local branch is a risk not to update the latest one and to implement
original bugs, rather than it is a troublesome task.

Please any comments, and feel free to ask any question.

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

Mime
View raw message