[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#23661: usr/doc should not be accessible through http servers by default



On Tue, Jun 20, 2000 at 09:58:01AM +0100, Julian Gilbey wrote:
> Here's an issue.  About two years ago there was a proposal that the
> default httpd setup should not allow /usr/doc to be remotely
> accessible, as it's a huge security risk.  (Yes, we're talking about a
> small amount of "security through obscurity" here, but we don't need
> to hand crackers this information on a golden plate.)
> 
> Nothing appears to have been done about it.
> 
> Where do we go from here?  Do we steam ahead and make it policy or
> what?  Are there any good reasons why this *shouldn't* be done?

In my opinion, this is true of all services.  Exporting them to all
connected systems by default is a security risk.  And, while there's a lot
we could do if the technology were better, we could at least have some
sort of file in /etc which defines some basic policy about such things
-- export by default vs. localhost only vs. ask user vs. export only
"the important stuff" by default [which, unfortnately, is undecidable,
but it's worth mentioning if only for contrast].

I've suggested this earlier, and had ipchains recommended to me.

Unfortunately, ipchains really is inadequate for this purpose -- ipchains
must make decisions based on protocol, ip addr, and ip port -- it doesn't
have the capability to make decisions based on the program(s) involved.
Thus, ipchains is completely useless for rpc, almost useless for udp
[unless you want to turn off dns], and somewhat useless for a system
which must allow non-PASV ftp.

What would be "really nice", of course, would be an enhancement to
ipchains which let you make decisions on a per-program basis.  But,
since we don't have that, I think we need a little more attention on
getting the user involved in the configuration of exported services.

And, of course, ipchains will never solve issues like exporting /usr/doc/
along with /var/www/.

My guess is that debconf could be pressed into service, here.  For woody,
it would be nice to have a whole category of optional questions related to
"do you want this exported or not".  Share some initial leading question
or three, so that people can choose whether they want this level of detail
at config time, and then leave the rest up to package implementation.

-- 
Raul



Reply to: