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 <[email protected]>
