[gopher] Re: [Fwd: Re: Gopher+ Suggestion]

[John Goerzen <jgoerzen@xxxxxxxxxxxx>]

On Monday, July 22, 2002, at 11:51 PM, R. Cooley wrote:

>It's good to know that pyGopherd will be modified...  However, I'm not 
>a python fan.  I would like to see gopher-3.0.x 
>(gopher://quux.org/1/devel/gopher) with such a modifcation.

Well, you don't have to know Python in order to use pygopherd, nor do 
you have to know Perl to use Bucktooth.  Right now, I'm not planning on 
adding any new features to the gopherd tree (though that could change in 
the future).  It's a lot more difficult to modify it than PyGopherd.

PyGopherd supports everything UMN gopherd does, with the exception of 
ASK blocks and Gopher authentication (which is somewhat broken in UMN 
gopherd anyway).  I have made a point to make PyGopherd compatible with 
UMN dotfiles, to the point that I was able to switch quux.org over from 
UMN gopherd to PyGopherd without modifying anything.

>How about a small list of open source programs that should have droped 
>privlidges, but didin't.  Programs under a good deal of scrutiny, like 
>vixie cron, and rsync.

Please don't assume that anything I said could be construed to mean that 
the problem does not exist.  I am well aware that it does.

Why are you more likely to trust the "su" or "login" program to drop 
privileges than you are to trust PyGopherd?  There have been security 
flaws in PAM and login before.

>When Apache and OpenSSH were found vulnerable, I thought people were 
>sure to do anything they could do, to lockdown services.  I'm surprised 
>to see that nothing has really changed.

I don't quite follow.

>If I trusted any piece of software, I wouldn't be a very good system 
>administrator, now would I?  I trust nothing, and always have several 
>layers of

Sorry, my sentance was unclear.  I meant that I trust PyGopherd 
completely to drop privileges.

>security:  running services as users with restrictive permissions.  
>Incredibly restrictive firewalls.  Soon, I'll be using systrace 
>policies as well.
>
>Even if a catastrophic bug is found in gopherd (which is quite 
>possible), the effects to any of ,y systems are minimal, if it's even 
>exploitable.  Of course, you are free to be far less paranoid than 
>myself.

You seem to trust your own setup.  That's one flaw in the "trust 
nothing" part.  By not runing chroot, the process does have access to 
other areas on your system, conceivably being able to read /etc/passwd 
to gather a list of users on the box, etc.  This is why I advocate 
running chroot.

Consider what would happen if gopherd were compromised in your 
situation.  It would, at minimum, have read/write access to the 
repository, and read access to /usr, /etc, etc.  It could exec anything 
that's world-accessible, possibly including setuid programs.

Now consider what would happen if you are runing chroot and there was a 
more catastrophic flaw, one that resulted from not dropping privileges, 
and suddenly the process is running attacker's code as root.  The 
process will have read/write access to the repository, same as before, 
but since it's running chrooted, it cannot read or write anything else.  
Even if there were a privilege dropping problem, it would be safe.  I 
modified UMN gopherd some time back to move the chrooting to be eariler 
in the lifespan of the program, so that it is chrooted before listening 
to any requests from the network.  That way, once it forks off a worker 
process to handle a request, it's already permanently chrooted.

Now, having said all that, I should say that I am not completely 
satisfied with the security of the gopherd code.  It needs an extensive 
audit.  I've already cleaned up a lot.  I'm a lot more comfortable with 
the PyGopherd codebase, but of course it would be foolish to state that 
any software of any siginficant size is 100% bug-free.

-- John