lkml.org 
[lkml]   [2002]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: lan based kgdb
a couple quick questions from an end-user

1. will an interface be dedicated to this use, or will it share an
interface with other traffic.

2. if it is dedicated how do you inform the rest of the system that this
card is off limits? (and can you use one port on a quad card, or do you
require a dedicated card?)

3. if we really want to make this limited to the local wire why not use
something other then UDP? either another IP protocol number (more likly to
be blocked by routers) or somethign not IP compatable (so that routers
couldn't forward it if they wanted to). especially if you are talking
about useing a special (aka stripped down, simplified) stack for this
interface instead of the full-blown version

normally I would agree that standards are good, becouse they let you
interoperate with other equipment, but in this case I'm not sure that's
really what we want. All communications is not IP :-)

as someone managing 60 or so remote boxes, this sounds really nice, if it
can be made to work securely.

David Lang


On 17 Nov 2002 ebiederm@xmission.com wrote:

> Date: 17 Nov 2002 14:30:00 -0700
> From: ebiederm@xmission.com
> To: Brad Hards <bhards@bigpond.net.au>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Subject: Re: lan based kgdb
>
> Brad Hards <bhards@bigpond.net.au> writes:
>
> > On Mon, 18 Nov 2002 06:42, Eric W. Biederman wrote:
> > > As long as the network console/debug interface includes basic a basic
> > > check to verify that the packets it accepts are from the local network.
> > This is pretty hard to do in some configurations. You essentially have to do
> > this at the router, not at destination.
>
> I agree that you cannot do a perfect job. The goal is to get something
> that is good enough so that it can be enabled and not give an automatic root
> exploit if someone accidentally leaves it on at the wrong time.
>
> > > And it's outgoing packets have a ttl of one. I don't have a problem.
> > Recent IETF work on link-local has used TTL=255 outgoing, and it has to be 255
> > at the receive end too. That is a reasonable way to ensure that is is
> > link-local, since even the most brain-dead routers will at least decrement
> > TTL.
>
> Nice. And then on the transmit end I would still use a TTL=1 so that
> routers will refuse to route the packets. A bit asymmetric but I only
> care about security in one direction.
>
> But in what kind of configurations is checking the ip against the
> current netmask insufficient? Checking for a TTL of 255 will
> trivially make the check stronger.
>
> Having a network console for various debugging tasks could be very
> useful. The question is how to implement it simply and reliably.
>
> Eric
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:31    [W:0.060 / U:0.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site