httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Clark <mich...@metaparadigm.com>
Subject Re: [RFC] Apache Privilege Separation for WebDAV (now against 2.2.6)
Date Thu, 20 Dec 2007 04:31:06 GMT
Paul Querna wrote:
> Michael Clark wrote:
>> Hi Folks,
>>
>> I posted a note about my privilege separation patches the other day
>> and received some good private help/feedback, and have now made the
>> patches a considerable amount more portable and they are using apr
>> much more extensively.
>>
>> The patch is now fully modular and allows mod_privsep to be compiled
>> out (although it does add some additional hooks to the core).
>
> First off, I want to say, this is a very cool set of patches, and I 
> would like to see it or some derivative go into trunk!

Thanks. BTW - I have filled out and sent in a CLA about a week ago.

I'll send an email later about issues that I think should be addressed 
before a possibility of this or some derivative going in (perhaps just 
the required vfs hooks).

There are also alternative approaches I'd like to mention - such as an 
mpm with non-privileged accept threads that forward the accepted socket 
to a dynamic pool of processes running as the desired uid - they could 
be created on demand (out of band by a privileged parent process) for 
authenticated users with a minimum pool size of 0 and timed out and 
killed after so many seconds of inactivity. This would also get rid of 
BIG_SECURITY_HOLE as there would be no race with the accept thread 
running as root (as with the other approaches I've seen).

The advantage of this approach over the privsep patches' approach would 
be higher performance as there would be no ping/pong for each stat/open 
call although I don't think it would be quite as anally secure as my 
approach (That said, it could still check a signed token in a separated 
process before forwarding the accepted socket to reduce the potential of 
a buffer overflow exploit in one of the unprivileged processes allowing 
access as another uid). To do it this way we would need the ability to 
forward a request mid-processing (need to see host headers, translated 
path and authenticate before forwarding it) - so the process that gets 
forwarded the accepted socket would need to receive the headers out of 
band (perhaps in the message sending the accepted socket). This approach 
would be more intrusive to the core than my current approach I think 
(although it wouldn't need the modules to use hooked io functions).

There would still be the issue of needing the stat calls in 
ap_directory_walk needing to be done with higher privs before the 
map_to_storage and access hooks have completed (so this approach may 
still benefit from the privilege separated process - it is also needed 
for system authentication in the PAM case if using /etc/shadow).

Although I think the privsep patch approach is valid given a pluggable 
vfs io layer which has the request_rec as context - it could then be 
done unobtrusively. Perhaps I should add some notes to the 
PrivilegeSeparation wiki page on wiki.apache.org?

>> Due to the nature of the patch it has to change some core code
>> to use privileged wrapper calls for file io. I can't see any way
>> around this - I have tried to minimise the impact by adding hooks.
>>
>
> How you stubbed out the file io seems fine for the lifetime of 2.2.x 
> and maybe 2.4.x, but in the long run, I believe we need to support 
> some kind of "VFS" layer, to make all IO pluggable. (open file, 
> directory listing, etc etc).
>

Yes. It would be nice to get some core changes that would support this 
patch as an external module until it is ready (and make the filesystem 
IO layer generally pluggable). Either way, I think having a pluggable IO 
layer would be a good idea.

The core patch could be made more palatable by making the apr IO hook 
API not privsep specific. So we could change the core patch as follows:

* Rename server/privsep.c -> server/vfs.c
* Rename include/privsep.h -> include/vfs.h
* Rename layered APR io calls from ap_privsep_<foo> to ap_vfs_<foo>
* Change context argument on io hooks calls from privsep_token_t* to 
request_rec*

Shall I run up a patch set like this? This could perhaps be a starting 
point for a vfs (I believe request_rec* would be the correct context for 
these vfs indirected calls?).

There is only one place I need more context information than the 
request_rec structure - this is for the apr_stat calls in 
ap_directory_walk before the map_to_storage and authentication hooks 
have completed. I can work around this somehow (by adding the preauth 
stat token to the request before doing these stat calls - or perhaps 
hook ap_directory_walk in this vfs).

Later the hook dispatcher in vfs.c (server/privsep.c) could be modified 
to use the context/config from request_rec to work out where to dispatch 
the io calls rather than the simple dispatch all calls here approach I 
have currently. We could then have an ap_vfs_mount API to hook which 
paths we want to go where.

> Preferably Async IO and pluggable too :-)

The current approach doesn't preclude async IO as the returned file 
descriptors inside of the apr_file_t could have async io operations 
performed on them.

Although, yes a more general approach would be needed to get the 
apr_file_open/apr_stat/etc to be performed asynchronously.

> Dream mode on:
> <Location /upload>
>    Dav On
>    Mount privsep:/opt/upload
> </Location>
>
> # static content
> <Location /mysite>
>    Mount /www/content
> </Location>
>
> # proxied content
> <Location /foo>
>    Mount balancer://bigcluster
> </Location>
>
> Anyways, if all IO was abstracted with a little VFS layer, it would 
> mean all modules would now work with your privilege separation code, 
> rather than just the core, mod_autoindex, and any other modules you 
> write patches for :-)

I like this idea.

Then the io hook layer (vfs) becomes justifiable on its own - and more 
code could be converted to use it.

Michael.


Mime
View raw message