> I am pro.
>
> It takes a root compromise to use it anyway, and its usefulness
> for DHCP and rarpd is too compelling.
>
> Perhaps the comments in the GENERIC file could be updated.
Well, given that I've gotten primarily positive support for this I
guess it's time to do it. Warner, do you want
> This is a clear security vs functionality issue and I need to get a
> good feel for which "cause" is ascendent here in knowing which way to
> jump on the matter. Can we now hear the closing arguments from the
> pro and con folks?
I am pro.
It takes a root compromise to use it anyway, and its u
> I am pro.
>
> It takes a root compromise to use it anyway, and its usefulness
> for DHCP and rarpd is too compelling.
>
> Perhaps the comments in the GENERIC file could be updated.
Well, given that I've gotten primarily positive support for this I
guess it's time to do it. Warner, do you wan
> This is a clear security vs functionality issue and I need to get a
> good feel for which "cause" is ascendent here in knowing which way to
> jump on the matter. Can we now hear the closing arguments from the
> pro and con folks?
I am pro.
It takes a root compromise to use it anyway, and its
In message <37a3b701.851df...@softweyr.com> Wes Peters writes:
>Do we have a list of all services that use bpf?
In the base system, ipfilter et al (ie ipsend(1)), tcpdump,
rbootd, rarpd and dhcp. Someone who's got a complete set of ports
might like to comment on what ports need bpf.
Of these, we
In message <[EMAIL PROTECTED]> Wes Peters writes:
>Do we have a list of all services that use bpf?
In the base system, ipfilter et al (ie ipsend(1)), tcpdump,
rbootd, rarpd and dhcp. Someone who's got a complete set of ports
might like to comment on what ports need bpf.
Of these, we need to lea
On Sun, Aug 01, 1999 at 10:17:54AM -0400, Sergey Babkin wrote:
> Warner Losh wrote:
> >
> > In message <37a3b701.851df...@softweyr.com> Wes Peters writes:
> > : Do we have a list of all services that use bpf? I'm willing to edit the
> > man
> > : pages, given a list. I guess I could just grep-o
On Sun, Aug 01, 1999 at 10:17:54AM -0400, Sergey Babkin wrote:
> Warner Losh wrote:
> >
> > In message <[EMAIL PROTECTED]> Wes Peters writes:
> > : Do we have a list of all services that use bpf? I'm willing to edit the man
> > : pages, given a list. I guess I could just grep-o-matic here, huh?
Warner Losh wrote:
>
> In message <37a3b701.851df...@softweyr.com> Wes Peters writes:
> : Do we have a list of all services that use bpf? I'm willing to edit the man
> : pages, given a list. I guess I could just grep-o-matic here, huh?
>
> Yes. I'm also in a holding off pattern until we know t
Warner Losh wrote:
>
> In message <[EMAIL PROTECTED]> Wes Peters writes:
> : Do we have a list of all services that use bpf? I'm willing to edit the man
> : pages, given a list. I guess I could just grep-o-matic here, huh?
>
> Yes. I'm also in a holding off pattern until we know the exact imp
In message <37a3b701.851df...@softweyr.com> Wes Peters writes:
: Do we have a list of all services that use bpf? I'm willing to edit the man
: pages, given a list. I guess I could just grep-o-matic here, huh?
Yes. I'm also in a holding off pattern until we know the exact impact
for all daemons
In message <[EMAIL PROTECTED]> Wes Peters writes:
: Do we have a list of all services that use bpf? I'm willing to edit the man
: pages, given a list. I guess I could just grep-o-matic here, huh?
Yes. I'm also in a holding off pattern until we know the exact impact
for all daemons that use th
Matthew Dillon wrote:
>
> :> consistant with the meaning of "raw devices".
> :
> :Disabling bpf it will break rarpd (and also rbootd but it is less
> :important). I think such a thing should be mentioned in documentation.
> :
> :-SB
>
> Not if rarpd is started via the rc files... it would hoo
Warner Losh wrote:
>
> In message <9518.933378...@zippy.cdrom.com> "Jordan K. Hubbard" writes:
> : > There are no security levels > 3. I'd be happy with > 0. This is
> : > consistant with the meaning of "raw devices".
> :
> : Would you be willing to make this change?
>
> Yes. I will make this
"Brian F. Feldman" wrote:
>
> On Fri, 30 Jul 1999, Brian F. Feldman wrote:
> >
> > In that case, my argument changes to:
> > "There's no good reason not to have bpf in the GENERIC kernel."
>
> And how about having
> if (securelevel > 3)
> return (EPERM);
> in bpf_open()?
"Jordan K. Hubbard" wrote:
>
> We got off onto a big tangent about switches and vlans and stuff and I
> learned a number of interesting things, don't get me wrong, but we
> still haven't established any consensus on the trade-offs of enabling
> bpf. This wasn't meant to be a hypothetical discussi
Matthew Dillon wrote:
>
> :> consistant with the meaning of "raw devices".
> :
> :Disabling bpf it will break rarpd (and also rbootd but it is less
> :important). I think such a thing should be mentioned in documentation.
> :
> :-SB
>
> Not if rarpd is started via the rc files... it would ho
Warner Losh wrote:
>
> In message <[EMAIL PROTECTED]> "Jordan K. Hubbard" writes:
> : > There are no security levels > 3. I'd be happy with > 0. This is
> : > consistant with the meaning of "raw devices".
> :
> : Would you be willing to make this change?
>
> Yes. I will make this change tomor
"Brian F. Feldman" wrote:
>
> On Fri, 30 Jul 1999, Brian F. Feldman wrote:
> >
> > In that case, my argument changes to:
> > "There's no good reason not to have bpf in the GENERIC kernel."
>
> And how about having
> if (securelevel > 3)
> return (EPERM);
> in bpf_open()?
"Jordan K. Hubbard" wrote:
>
> We got off onto a big tangent about switches and vlans and stuff and I
> learned a number of interesting things, don't get me wrong, but we
> still haven't established any consensus on the trade-offs of enabling
> bpf. This wasn't meant to be a hypothetical discuss
In message <19990731154458.a2...@netmonger.net> Christopher Masto writes:
: I hope you mean "> 1". I often diagnose problems using tcpdump etc.,
: and I don't think bpf should be broken just because someone wants the
: minor "flags can't be turned off" feature of level 1.
Flags can't be turned of
In message <19990731193410.c18...@cicely8.cicely.de> Bernd Walter writes:
: Maybe a set of sysctls with a switch to off only behavour would be a
: better way.
Actually, a better way would be to have the interfaces to the network
stack that would handle this stuff w/o needing to resort to bpf.
War
In message <19990731190814.a18...@cicely8.cicely.de> Bernd Walter writes:
: > There are no security levels > 3. I'd be happy with > 0. This is
: > consistant with the meaning of "raw devices".
: That would mean you can't run a secured DHCP server :(
No. That would mean you'd have to start DHCP
In message <[EMAIL PROTECTED]> Bernd Walter writes:
: > There are no security levels > 3. I'd be happy with > 0. This is
: > consistant with the meaning of "raw devices".
: That would mean you can't run a secured DHCP server :(
No. That would mean you'd have to start DHCP before raising the
se
In message <[EMAIL PROTECTED]> Christopher Masto writes:
: I hope you mean "> 1". I often diagnose problems using tcpdump etc.,
: and I don't think bpf should be broken just because someone wants the
: minor "flags can't be turned off" feature of level 1.
Flags can't be turned off at level 1, an
In message <[EMAIL PROTECTED]> Bernd Walter writes:
: Maybe a set of sysctls with a switch to off only behavour would be a
: better way.
Actually, a better way would be to have the interfaces to the network
stack that would handle this stuff w/o needing to resort to bpf.
Warner
To Unsubscribe:
On Fri, Jul 30, 1999 at 05:42:57PM -0600, Warner Losh wrote:
> In message
> "Brian F. Feldman" writes:
> : And how about having
> : if (securelevel > 3)
> : return (EPERM);
> : in bpf_open()?
>
> There are no security levels > 3. I'd be happy with > 0. This is
> consistant with
On Fri, Jul 30, 1999 at 05:42:57PM -0600, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> "Brian F.
>Feldman" writes:
> : And how about having
> : if (securelevel > 3)
> : return (EPERM);
> : in bpf_open()?
>
> There are no security levels > 3. I'd be happy with > 0. This i
On Sat, 31 Jul 1999, Ben Rosengart wrote:
> > That would mean you can't run a secured DHCP server :(
>
> I think only the client needs BPF. Anyway, you just start the server in
> the rc files, before securelevel is raised.
The isc dhcp server doesn't support a -SIGHUP reload, which would mean
a
On Sat, 31 Jul 1999, Ben Rosengart wrote:
> > That would mean you can't run a secured DHCP server :(
>
> I think only the client needs BPF. Anyway, you just start the server in
> the rc files, before securelevel is raised.
The isc dhcp server doesn't support a -SIGHUP reload, which would mean
On Sat, Jul 31, 1999 at 01:17:44PM -0400, Ben Rosengart wrote:
> On Sat, 31 Jul 1999, Bernd Walter wrote:
>
> > That would mean you can't run a secured DHCP server :(
>
> I think only the client needs BPF. Anyway, you just start the server in
> the rc files, before securelevel is raised.
AFAIK i
On Sat, 31 Jul 1999, Bernd Walter wrote:
> That would mean you can't run a secured DHCP server :(
I think only the client needs BPF. Anyway, you just start the server in
the rc files, before securelevel is raised.
--
Ben
UNIX Systems Engineer, Skunk Group
StarMedia Network, Inc.
To Unsubs
On Fri, Jul 30, 1999 at 05:42:57PM -0600, Warner Losh wrote:
> In message
> "Brian F. Feldman" writes:
> : And how about having
> : if (securelevel > 3)
> : return (EPERM);
> : in bpf_open()?
>
> There are no security levels > 3. I'd be happy with > 0. This is
> consistant with
On Sat, Jul 31, 1999 at 01:17:44PM -0400, Ben Rosengart wrote:
> On Sat, 31 Jul 1999, Bernd Walter wrote:
>
> > That would mean you can't run a secured DHCP server :(
>
> I think only the client needs BPF. Anyway, you just start the server in
> the rc files, before securelevel is raised.
AFAIK
On Sat, 31 Jul 1999, Bernd Walter wrote:
> That would mean you can't run a secured DHCP server :(
I think only the client needs BPF. Anyway, you just start the server in
the rc files, before securelevel is raised.
--
Ben
UNIX Systems Engineer, Skunk Group
StarMedia Network, Inc.
To Unsub
On Fri, Jul 30, 1999 at 05:42:57PM -0600, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> "Brian F.
>Feldman" writes:
> : And how about having
> : if (securelevel > 3)
> : return (EPERM);
> : in bpf_open()?
>
> There are no security levels > 3. I'd be happy with > 0. This i
Warner Losh wrote:
>
> In message <37a25361.34799...@bellatlantic.net> Sergey Babkin writes:
> : Disabling bpf it will break rarpd (and also rbootd but it is less
> : important). I think such a thing should be mentioned in documentation.
>
> Not if they are started before the secure level is rais
Warner Losh wrote:
>
> In message <[EMAIL PROTECTED]> Sergey Babkin writes:
> : Disabling bpf it will break rarpd (and also rbootd but it is less
> : important). I think such a thing should be mentioned in documentation.
>
> Not if they are started before the secure level is raised.
A problem i
"Jordan K. Hubbard" wrote:
>
> We got off onto a big tangent about switches and vlans and stuff and I
> learned a number of interesting things, don't get me wrong, but we
> still haven't established any consensus on the trade-offs of enabling
> bpf. This wasn't meant to be a hypothetical discussi
"Jordan K. Hubbard" wrote:
>
> We got off onto a big tangent about switches and vlans and stuff and I
> learned a number of interesting things, don't get me wrong, but we
> still haven't established any consensus on the trade-offs of enabling
> bpf. This wasn't meant to be a hypothetical discuss
In message <37a25361.34799...@bellatlantic.net> Sergey Babkin writes:
: Disabling bpf it will break rarpd (and also rbootd but it is less
: important). I think such a thing should be mentioned in documentation.
Not if they are started before the secure level is raised.
Warner
To Unsubscribe: s
In message <[EMAIL PROTECTED]> Sergey Babkin writes:
: Disabling bpf it will break rarpd (and also rbootd but it is less
: important). I think such a thing should be mentioned in documentation.
Not if they are started before the secure level is raised.
Warner
To Unsubscribe: send mail to [EMA
:> consistant with the meaning of "raw devices".
:
:Disabling bpf it will break rarpd (and also rbootd but it is less
:important). I think such a thing should be mentioned in documentation.
:
:-SB
Not if rarpd is started via the rc files... it would hook up to bpf
prior to the secureleve
Warner Losh wrote:
>
> In message
> "Brian F. Feldman" writes:
> : And how about having
> : if (securelevel > 3)
> : return (EPERM);
> : in bpf_open()?
>
> There are no security levels > 3. I'd be happy with > 0. This is
> consistant with the meaning of "raw devices".
Dis
:In message <9518.933378...@zippy.cdrom.com> "Jordan K. Hubbard" writes:
:: > There are no security levels > 3. I'd be happy with > 0. This is
:: > consistant with the meaning of "raw devices".
::
:: Would you be willing to make this change?
:
:Yes. I will make this change tomorrow unless there
:> consistant with the meaning of "raw devices".
:
:Disabling bpf it will break rarpd (and also rbootd but it is less
:important). I think such a thing should be mentioned in documentation.
:
:-SB
Not if rarpd is started via the rc files... it would hook up to bpf
prior to the securelev
Warner Losh wrote:
>
> In message <[EMAIL PROTECTED]> "Brian F.
>Feldman" writes:
> : And how about having
> : if (securelevel > 3)
> : return (EPERM);
> : in bpf_open()?
>
> There are no security levels > 3. I'd be happy with > 0. This is
> consistant with the meaning of
:In message <[EMAIL PROTECTED]> "Jordan K. Hubbard" writes:
:: > There are no security levels > 3. I'd be happy with > 0. This is
:: > consistant with the meaning of "raw devices".
::
:: Would you be willing to make this change?
:
:Yes. I will make this change tomorrow unless there is signific
In message <9518.933378...@zippy.cdrom.com> "Jordan K. Hubbard" writes:
: > There are no security levels > 3. I'd be happy with > 0. This is
: > consistant with the meaning of "raw devices".
:
: Would you be willing to make this change?
Yes. I will make this change tomorrow unless there is sig
> There are no security levels > 3. I'd be happy with > 0. This is
> consistant with the meaning of "raw devices".
Would you be willing to make this change?
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
In message
Alfred Perlstein writes:
: What about the one-way sysctls that have been suggested?
They need to be implemente dfirst. A quick securelevel > 0 in bpf_open
would allow many people's objections to bpf in the kernel by default.
Warner
To Unsubscribe: send mail to majord...@freebsd.o
On Fri, 30 Jul 1999, Warner Losh wrote:
> In message
> "Brian F. Feldman" writes:
> : And how about having
> : if (securelevel > 3)
> : return (EPERM);
> : in bpf_open()?
>
> There are no security levels > 3. I'd be happy with > 0. This is
> consistant with the meaning of "raw
In message "Brian
F. Feldman" writes:
: And how about having
: if (securelevel > 3)
: return (EPERM);
: in bpf_open()?
There are no security levels > 3. I'd be happy with > 0. This is
consistant with the meaning of "raw devices".
Warner
To Unsubscribe: send mail to ma
In message <8605.933365...@zippy.cdrom.com> "Jordan K. Hubbard" writes:
: It already is. That's not the question under discussion here - we're
: talking about how to make things work in the post-installation boot
: scenario.
I'm in favor of having it in the kernel by default. With one
proviso.
In message <[EMAIL PROTECTED]> "Jordan K. Hubbard" writes:
: > There are no security levels > 3. I'd be happy with > 0. This is
: > consistant with the meaning of "raw devices".
:
: Would you be willing to make this change?
Yes. I will make this change tomorrow unless there is significant
obj
> There are no security levels > 3. I'd be happy with > 0. This is
> consistant with the meaning of "raw devices".
Would you be willing to make this change?
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
In message <[EMAIL PROTECTED]>
Alfred Perlstein writes:
: What about the one-way sysctls that have been suggested?
They need to be implemente dfirst. A quick securelevel > 0 in bpf_open
would allow many people's objections to bpf in the kernel by default.
Warner
To Unsubscribe: send mail to
On Fri, 30 Jul 1999, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> "Brian F.
>Feldman" writes:
> : And how about having
> : if (securelevel > 3)
> : return (EPERM);
> : in bpf_open()?
>
> There are no security levels > 3. I'd be happy with > 0. This is
> consistant with
In message <[EMAIL PROTECTED]> "Brian F.
Feldman" writes:
: And how about having
: if (securelevel > 3)
: return (EPERM);
: in bpf_open()?
There are no security levels > 3. I'd be happy with > 0. This is
consistant with the meaning of "raw devices".
Warner
To Unsubscr
In message <[EMAIL PROTECTED]> "Jordan K. Hubbard" writes:
: It already is. That's not the question under discussion here - we're
: talking about how to make things work in the post-installation boot
: scenario.
I'm in favor of having it in the kernel by default. With one
proviso. Any place wh
> I thought we decided that the networking gurus we're going to make it
> possible to send out broadcast packets on an unconfigured interface so
> that DHCP would work, so that bpf wasn't required.
I believe we decided that this would be the preferred method, yes. I
don't think, however, that we
On Fri, 30 Jul 1999, Nate Williams wrote:
> > This is a clear security vs functionality issue and I need to get a
> > good feel for which "cause" is ascendent here in knowing which way to
> > jump on the matter. Can we now hear the closing arguments from the
> > pro and con folks?
>
> I thought
:> BTW, I wrote this section because a hacker actually installed the bpf
:> device via the module loader during one of the root compromises at BEST,
:> a year or two ago. He had gotten it from a hackers cookbook of exploits
:> which he convieniently left on-disk long enough for ou
> This is a clear security vs functionality issue and I need to get a
> good feel for which "cause" is ascendent here in knowing which way to
> jump on the matter. Can we now hear the closing arguments from the
> pro and con folks?
I thought we decided that the networking gurus we're going to mak
> : But even if you turn off the bpf device, you still have /dev/mem and
> : /dev/kmem to worry about. For that matter, the intruder can still write
> : raw devices. Also, there is another kernel feature called kldload(8).
>
> BTW, I wrote this section because a hacker actually i
On Fri, 30 Jul 1999, Matthew Dillon wrote:
> : But even if you turn off the bpf device, you still have /dev/mem and
> : /dev/kmem to worry about. For that matter, the intruder can still write
> : raw devices. Also, there is another kernel feature called kldload(8).
>
> BTW, I wr
: But even if you turn off the bpf device, you still have /dev/mem and
: /dev/kmem to worry about. For that matter, the intruder can still write
: raw devices. Also, there is another kernel feature called kldload(8).
BTW, I wrote this section because a hacker actually installed t
On Fri, 30 Jul 1999, Brian F. Feldman wrote:
> On Fri, 30 Jul 1999, Jordan K. Hubbard wrote:
>
> > > There's no good reason to not have bpf in at least the boot disk kernel.
> >
> > It already is. That's not the question under discussion here - we're
> > talking about how to make things work in
> I thought we decided that the networking gurus we're going to make it
> possible to send out broadcast packets on an unconfigured interface so
> that DHCP would work, so that bpf wasn't required.
I believe we decided that this would be the preferred method, yes. I
don't think, however, that we
On Fri, 30 Jul 1999, Jordan K. Hubbard wrote:
> > There's no good reason to not have bpf in at least the boot disk kernel.
>
> It already is. That's not the question under discussion here - we're
> talking about how to make things work in the post-installation boot
> scenario.
When did that hap
On Fri, 30 Jul 1999, Nate Williams wrote:
> > This is a clear security vs functionality issue and I need to get a
> > good feel for which "cause" is ascendent here in knowing which way to
> > jump on the matter. Can we now hear the closing arguments from the
> > pro and con folks?
>
> I thought
> There's no good reason to not have bpf in at least the boot disk kernel.
It already is. That's not the question under discussion here - we're
talking about how to make things work in the post-installation boot
scenario.
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubs
> It will let us use a dhcp client in the install programs, this is of
> tremendous use to many people as DHCP starts to become much more
> popular. I cannot net install a machine at home since that is on a
> DHCP cable modem service.
Well, just to clarify this, if you're installing a 4.0 snapsho
If root is compromised, that's the only way bpf can be gotten to by
default. When root's compromised, if no bpf is available, the mem devices
can still be created (if not there) and network queues can be listened to.
And can't IFF_PROMISC be turned on too?
There's no good reason to not have bpf in
Here is a pro vote for enabling BPF in GENERIC:
It will let us use a dhcp client in the install programs, this is of tremendous
use to many people as DHCP starts to become much more popular. I cannot
net install a machine at home since that is on a DHCP cable modem service.
Also, if root is comp
:> BTW, I wrote this section because a hacker actually installed the bpf
:> device via the module loader during one of the root compromises at BEST,
:> a year or two ago. He had gotten it from a hackers cookbook of exploits
:> which he convieniently left on-disk long enough for o
> This is a clear security vs functionality issue and I need to get a
> good feel for which "cause" is ascendent here in knowing which way to
> jump on the matter. Can we now hear the closing arguments from the
> pro and con folks?
I thought we decided that the networking gurus we're going to ma
> : But even if you turn off the bpf device, you still have /dev/mem and
> : /dev/kmem to worry about. For that matter, the intruder can still write
> : raw devices. Also, there is another kernel feature called kldload(8).
>
> BTW, I wrote this section because a hacker actually
On Fri, 30 Jul 1999, Matthew Dillon wrote:
> : But even if you turn off the bpf device, you still have /dev/mem and
> : /dev/kmem to worry about. For that matter, the intruder can still write
> : raw devices. Also, there is another kernel feature called kldload(8).
>
> BTW, I w
: But even if you turn off the bpf device, you still have /dev/mem and
: /dev/kmem to worry about. For that matter, the intruder can still write
: raw devices. Also, there is another kernel feature called kldload(8).
BTW, I wrote this section because a hacker actually installed
On Fri, 30 Jul 1999, Brian F. Feldman wrote:
> On Fri, 30 Jul 1999, Jordan K. Hubbard wrote:
>
> > > There's no good reason to not have bpf in at least the boot disk kernel.
> >
> > It already is. That's not the question under discussion here - we're
> > talking about how to make things work i
On Fri, 30 Jul 1999, Jordan K. Hubbard wrote:
> > There's no good reason to not have bpf in at least the boot disk kernel.
>
> It already is. That's not the question under discussion here - we're
> talking about how to make things work in the post-installation boot
> scenario.
When did that ha
> There's no good reason to not have bpf in at least the boot disk kernel.
It already is. That's not the question under discussion here - we're
talking about how to make things work in the post-installation boot
scenario.
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscri
> It will let us use a dhcp client in the install programs, this is of
> tremendous use to many people as DHCP starts to become much more
> popular. I cannot net install a machine at home since that is on a
> DHCP cable modem service.
Well, just to clarify this, if you're installing a 4.0 snapsh
If root is compromised, that's the only way bpf can be gotten to by
default. When root's compromised, if no bpf is available, the mem devices
can still be created (if not there) and network queues can be listened to.
And can't IFF_PROMISC be turned on too?
There's no good reason to not have bpf i
Here is a pro vote for enabling BPF in GENERIC:
It will let us use a dhcp client in the install programs, this is of tremendous
use to many people as DHCP starts to become much more popular. I cannot
net install a machine at home since that is on a DHCP cable modem service.
Also, if root is com
86 matches
Mail list logo
