I know I don't have the same credentials as some of the net.gods that post here, but as a maintainer of the web server Boa, and a generally active *nix user/programmer/admin who cares about security, I'd like to weigh in on the subject of web server setup and more general issues of computer security technique. I hope this essay doesn't come across as too pedestrian or long-winded. There is certainly some value in not leaking machine configuration onto the net at large. In a perfect world, it wouldn't matter, but people and their software are not perfect [1]. OTOH, you would rightly ignore an assertion that zyxmail was insecure, because any user on the system can use it to send a copy of /etc/passwd to alt.2600. Hey, you're the one who gave the luser an account, you can yank it too. Why, then, should one be concerned that a user can "ln -s / $HOME/public_html"? I know Apache can be configured to not follow symbolic links from user directories [2]. Many other programs, Boa included, don't attempt to recreate or second guess the protection mechanisms built into the OS they run under. This is a personal beef I have with people who ask for, and programmers that provide, bloated programs. Daemons run with the uid/gid selected by the sysadmin [3], typically an "unprivileged user" [4]. The nominal expectation should be that remote users of a such a daemon can make it take any action on their behalf, limited by the permissions of that uid/gid. This is certainly true of Boa when semi-untrusted users are given control over part of the web virtual space, such as with the usual $HOME/public_html mechanism. It is also true of any daemon that has an exploitable buffer overflow bug; containing such attacks is a big motivation for using an untrusted uid in the first place. My recommendation: if you have semi-untrusted users on your system, and you consider some configuration files sufficiently sensitive that you don't want them splattered all over the internet, don't protect them 755 [5]. There are times when a webserver should show a different virtual spaces depending on from where the request comes in -- e.g., local, intranet, or big bad world [6]. I suspect this concept has to make it into the Debian web policy, in particular to show /doc to local users, but not the outside world. Of course, Apache can do that. With minor tweaks or hacks, most other web servers can too [7]. I have learned that the *nix security model, while less than perfect, is far more adaptable and flexible than most people give it credit for. Don't ignore it or fight it, use it to your advantage. - Larry Doolittle <ldoolittat_private> [1] It is actually quite reassuring that we have the time to worry about subtle information leakage. It doesn't seem like too long ago that bugtraq was full of instant remote root exploits. [2] Of course, to implement this, Apache stat()'s every component of the path on every request. [3] Or system integrator. People who put a Red Hat or other preconfigured system live on the 'net without investigating what's really there are fools. [4] Historically nobody/nogroup. This is arguably overused. A more modern setup allocates a specific uid/gid for each task. [5] I personally get frustrated trying to make such a machine work (in a mortal user role), because I can't self-diagnose problems. I found a "final solution" to this problem many years ago, now I have root privileges on my own machine. [6] Based on IP number, not name, of course. DNS is too slow for me, and raises security questions of its own. [7] I haven't checked how easy it is with the features of the Debian version of Boa. If someone tells me it's needed and will be used, _and_ gives a useful description of how to configure it, I can certainly program it. Test and internal use copies of Boa have already implemented features along this line.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:42:16 PDT