httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject Re: anonymous CVS access
Date Fri, 01 Aug 1997 02:37:17 GMT
At 01:11 PM 7/31/97 -0600, Marc Slemko wrote:
>> Nope, only folks whose passwords are in /export/apache/.htpasswd-dbm
>> We could make that more secure by installing Apache-SSL too.
>Login to taz.  edit-pr.
>The way to fix the security would be to stop the setuid gnats programs
>from being world executable and using suexec on a seperate virtual host to
>run the bugdb script so it has access.

Okay, this is now done.  I have a "" vhost, under
/apache/bugs, which is setuid "apwww" (a new user I created) and setgid
"bugdb".  The director is also chown's apwww.bugdb, and the scripts are
mode 700.  So to update it I'd need to give someone the password to apwww,
or sudo privileges; not a problem I guess, but it means a manual process to
move bugdb.cgi there each time it gets updated.  Under there I put the
bugdb.cgi script as "index.cgi".  And I set up a redirect from to that.

In addition, I set up a "private" directory, gave it the same access config
as, and redirected to

Verifying that all that worked as anticipated, and that the group id was
being set right, I changed the permissions on the suexec "pr-edit" program
to 4750.  Again, all worked as expected, so I added the other members of
the group "httpd" to the group "bugdb".  Hey, do any Unices out there have
hierarchical user grouping?  Hmm....

Anyways, it looks to be safe.  There are a couple other world-executable
setuid programs in gnats - gen-index and queue-pr.  I think I can get
queue-pr to be non-world-executable (it is now because it's triggered by an
entry in /etc/aliases, but I can easily make that a .forward-based program
so it's gnats's uid.)  I don't know what gen-index does, or more
importantly who calls it, but I bet it'd be safe to make that mode 4750 too.

Also I need to upgrade to gants 4 when it comes out of beta.  And someone
might want to examine it for buffer overflows anyways, since a bad message
to apbugs might still cause a hole somewhere to the "gnats" user.  

In all of this, the threat is that someone could gain access to the "gnats"
user and wreck havoc on the bugdb.  

Marc, let me know if I overlooked something, and thanks for getting me off
my butt to do this.

>If each account has a 1% chance of being cracked, then if you have 200
>acounts you have a 87% chance of being cracked while if you have 20
>accounts you have an 18% chance of being cracked.  (yes, those numbers
>have 0 meaning but my point is the more users the more risk.)

More security breaches are done by exploiting holes in network daemons than
by gaining shell access due to password snooping or someone forgetting to
log out, at least that's how it seems to me based on watching security
forums for several years.  For any machine where you are running public
services, you have to consider the possibility of an unwanted individual
gaining shell access.  You can try and prevent that, but fundamentally your
machine as a whole isn't noticeably more secure just because it has fewer
logins, or even if the average security-awareness of your users is higher.  

There are probably more situations like the bugdb where things could be
made more secure; let's address them and clean it up, this one only took me
90 minutes.


"Why not?" - TL  - -

View raw message