Hi,
Though trying to provide the equivalent of /etc/hosts.{allow,deny}
for services not controlled by tcp wrappers and inetd is laudable,
this specific case could easily be addressed by a simple change in
the default access.conf (this is apache specific, I am sure other
servers have eq
>>"Steve" == Steve Robbins <[EMAIL PROTECTED]> writes:
Steve> I can think of one situation for which this is inconvenient.
Steve> If I set up a local net full of debian machines, only one of
Steve> which is running a web server, this change would prevent me
Steve> from using the web to browse
> > 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 l
On Tue, Jun 20, 2000 at 08:45:25AM -0400, Raul Miller wrote:
> 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
> "Martin" == Martin Schulze <[EMAIL PROTECTED]> writes:
Martin> 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
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
>
On Tue, Jun 20, 2000 at 02:35:45PM +0200, Petr Cech wrote:
> 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 securi
On Tue, Jun 20, 2000 at 09:13:47AM -0400, Steve Robbins 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 "sec
On Tue, 20 Jun 2000, 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" her
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 th
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 t
On Jun 20, Julian Gilbey <[EMAIL PROTECTED]> wrote:
>Where do we go from here? Do we steam ahead and make it policy or
>what?
Yes, please.
--
ciao,
Marco
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 informat
I have just noticed that this bug has been closed.
I can find no explanation for its closure in the BTS. I'm reopening
it pending discussion. See my other mails.
I agree with the suggestion, but think it should be widened to rarely
providing any public network services by default.
Ian.
14 matches
Mail list logo
