[RFC] New web server for bazaar

[James Blackwell]

On Mon, Sep 19, 2005 at 11:24:35AM +1000, Robert Collins wrote:
> On Sun, 2005-09-18 at 01:24 -0400, James Blackwell wrote:
> > > > I have ported the mercurial[*] web interfaces to bazaar-ng; an example
> > > > can be 
> > 
> > > I'd be surprised if that happened. As a full fledged standalone (that
> > > incidentally has a full built-in version of Bazaar-NG), its very useful
> > > though.
> > 
> > I guess I stand corrected. :|
> > 
> > I'm a bit surprised to hear this though. I'll certainly be more cautious
> > about which systems I installed bzr on. 

> You do know that *python* comes with -at least 1- full fledged
> webserver ?

I read that in a different post of yours, between what I wrote and what
you wrote. I don't quite consider them the same thing, as I feel
comfortable knowing that distros are pretty clear about what is getting
opened up where.

Are you going to argue that people shouldn't be more cautious whenever
a port is opened for LISTEN? If not, then we can stop here. :) 

This would make for a short and boring post, so I'll anticipate that your
next question is "Why is this different?".  In short, I know that bzr
would be running.

Though it would hit my radar, the installation of an class that provides a
web server as part of the language probably wouldn't phase me, because I
know the python guys wouldn't install something doing LISTEN on ports by
default. If they did anyways, I'm comfortable that Ubuntu or Debian would
inform me. 

Knowing beforehand that a program might open ports in LISTEN automatically
puts me into paranoid mode when it comes to machines that I have on or
outside the DMZ. Before I install a program that started listening to
ports on or outside the DMZ (I have two DMZs here),  I generally answer
the following questions:

 1. Is this tool likely to be run as root?
 2. If so, does it drop privs and if so, how soon?
 3. Which ports does it open up by default?
 4. Will this conflict with any other daemons running.
 5. How many people are likely looking at the code?
 6. How many other installs are there? (Think mine canaries)
 7. What security history does this tool have? 
 8. How active is development?
 9. What sort of security auditing is done by the project? 

Anything that opens up a port reachable to the outside world needs careful
auditing before it can reasonably be situated on or outside a DMZ. Though
I probably wouldn't spend too much time worried about buffer overflows,
I'd be curious to see if it could be tricked to proxying commands to
inside machines or rendering sensitive the limited sensitive data on the
machine to the outside world via an open door.

I have two other reasons for being extra-careful. The first reason is that
I'm a fixed target (That's "sitting duck" in chinese). The second, by
virtue of some of my non-work responsibilities,  is that I'm a juicy
target for irc script kiddies.

A "no warrenty, express or implied" doesn't get me much more than a
"whoops, we should have throught that through better" if that built in
server just happens to have a proxying vulnerability that exposed the
softer underbelly of my internal network.

I'm not very conversant with the plugin system yet. For all I know, if a
plugin exists in the right place then bzr is going to start up a webserver
by default every time the command is run -- even if by root*. If that were
a case, then all it would take is a simple honest coding mistake to expose
any file on the filesystem (see the old named conf problem for local
escalation of filesystem access) or to expose deeper levels of the network
(see the ancient apache proxy bug).


* Yes, I've had legitimate reasons to use RCSs with root privs for certain
  tasks in the past. 



--
 James Blackwell      |   Try out the blog planet for revision control
 Tell someone a joke! |   at http://planet.revisioncontrol.net
----------------------------------------------------------------------
GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400