[ VMWare ]
> what's needed is customer presence.
If people could send me an email address where I could send and state my
interest in a VMWare port for FreeBSD (I would of course pay for a copy
of VMWare if it existed), I'll do it.
The stuff on the WWW page is too 'generic', and I'd rather get i
[ VMWare ]
> what's needed is customer presence.
If people could send me an email address where I could send and state my
interest in a VMWare port for FreeBSD (I would of course pay for a copy
of VMWare if it existed), I'll do it.
The stuff on the WWW page is too 'generic', and I'd rather get
> 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
> 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
> > > > In particular, the changes I pointed out are not 'cleanups', but style
> > > > changes.
> > >
> > > When you make code readable, it's a cleanup.
> >
> > The code is *NO* more readable by you re-ordering lines and changes
> > whitespace.
>
> This is so very objective.
That's why it consi
> > > > > These were changes that were necessary to make ipfw readable enough
> > > > > that
> > > > > I could work with it in this area. They aren't just to clean it up, or
> > > > > just for change's sake. They need to stay in.
> > > >
> > > > C'mon now, re-ording the lines is *certainly* not n
> > > *rant on*
> > > Brian, FreeBSD isn't your private playground for playing around, this is
> > > a group project, and you gotta follow the rules, or you don't get to
> > > play with the rest of the folks
> >
> > The rules don't say "leave the code that you work with in a bigger mess than
>
> > > These were changes that were necessary to make ipfw readable enough that
> > > I could work with it in this area. They aren't just to clean it up, or
> > > just for change's sake. They need to stay in.
> >
> > C'mon now, re-ording the lines is *certainly* not necessary to work.
>
> That's t
> > > > In particular, the changes I pointed out are not 'cleanups', but style
> > > > changes.
> > >
> > > When you make code readable, it's a cleanup.
> >
> > The code is *NO* more readable by you re-ordering lines and changes
> > whitespace.
>
> This is so very objective.
That's why it cons
> > > @@ -302,14 +303,15 @@
> > > struct ifnet *rif, struct ifnet *oif)
> > > {
> > > if (ip) {
> > > + struct tcphdr *const tcp = (struct tcphdr *)((u_int32_t *)ip+ip->ip_hl);
> > > + struct udphdr *const udp = (struct udphdr *)((u_int32_t *)ip+ip->ip_hl);
> > > + struct icmp *const icmp =
> Index: src/sys/netinet/ip_fw.c
> ===
> RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v
> retrieving revision 1.114
> diff -u -r1.114 ip_fw.c
> --- ip_fw.c 1999/06/19 18:43:28 1.114
> +++ ip_fw.c 1999/07/28 06:29:07
> @@ -106,6
> > > > > These were changes that were necessary to make ipfw readable enough that
> > > > > I could work with it in this area. They aren't just to clean it up, or
> > > > > just for change's sake. They need to stay in.
> > > >
> > > > C'mon now, re-ording the lines is *certainly* not necessary t
> > > *rant on*
> > > Brian, FreeBSD isn't your private playground for playing around, this is
> > > a group project, and you gotta follow the rules, or you don't get to
> > > play with the rest of the folks
> >
> > The rules don't say "leave the code that you work with in a bigger mess than
> > > > Implementing it is the easy part, making sure it's the right thing to do
> > > > is the hard part.
> > >
> > > Well, the easy part is done, except for raising limits. Look:
> > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0
> > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via l
> > > These were changes that were necessary to make ipfw readable enough that
> > > I could work with it in this area. They aren't just to clean it up, or
> > > just for change's sake. They need to stay in.
> >
> > C'mon now, re-ording the lines is *certainly* not necessary to work.
>
> That's
> > > @@ -302,14 +303,15 @@
> > > struct ifnet *rif, struct ifnet *oif)
> > > {
> > > if (ip) {
> > > + struct tcphdr *const tcp = (struct tcphdr *)((u_int32_t *)ip+ip->ip_hl);
> > > + struct udphdr *const udp = (struct udphdr *)((u_int32_t *)ip+ip->ip_hl);
> > > + struct icmp *const icmp
> Index: src/sys/netinet/ip_fw.c
> ===
> RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v
> retrieving revision 1.114
> diff -u -r1.114 ip_fw.c
> --- ip_fw.c 1999/06/19 18:43:28 1.114
> +++ ip_fw.c 1999/07/28 06:29:07
> @@ -106,
> > > > Implementing it is the easy part, making sure it's the right thing to do
> > > > is the hard part.
> > >
> > > Well, the easy part is done, except for raising limits. Look:
> > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0
> > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via
> > Implementing it is the easy part, making sure it's the right thing to do
> > is the hard part.
>
> Well, the easy part is done, except for raising limits. Look:
> ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0
> ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0
> ipfw: limit 2 reach
> And then ... securelevel == 3 I think it is better NOT to permit
> 'sysctl -w', 'ipfw *' AND a logging limmit, just process the logfile
> faster to avoid DoS
The real issue we are dealing with is what happens at securelevel == 3.
What you are saying is that people shouldn't be allowed to modify
> > Implementing it is the easy part, making sure it's the right thing to do
> > is the hard part.
>
> Well, the easy part is done, except for raising limits. Look:
> ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0
> ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0
> ipfw: limit 2 reac
> And then ... securelevel == 3 I think it is better NOT to permit
> 'sysctl -w', 'ipfw *' AND a logging limmit, just process the logfile
> faster to avoid DoS
The real issue we are dealing with is what happens at securelevel == 3.
What you are saying is that people shouldn't be allowed to modify
> If it will get ALL of you to give it a rest, how about:
> per-rule logging limits
> logging limit raising
> logging limit resetting
> Which would all NOT affect the statistics?
We need more input from people who use the code, to make sure they don't
depend on the current 'featu
> If it will get ALL of you to give it a rest, how about:
> per-rule logging limits
> logging limit raising
> logging limit resetting
> Which would all NOT affect the statistics?
We need more input from people who use the code, to make sure they don't
depend on the current 'feat
> > > > Again, it's not a fix, it's a feature. Not being able to mess with
> > > > counters (logging or otherwise) is a feature. It may be a feature that
> >
> > > > you can do without, but that decision is not to be made lightly.
> > >
> > > I'm _saying_ to cr
> > Again, it's not a fix, it's a feature. Not being able to mess with
> > counters (logging or otherwise) is a feature. It may be a feature that
> > you can do without, but that decision is not to be made lightly.
>
> I'm _saying_ to create a completely separa
> > > I like the ability at secure level 3 to only reset the counters forward..
> > > It fits in with such things as the "append only" flag.
> >
> > Then we'd have to implement per-rule counters that default to
> > IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very
> > differ
> > > > One could argue that accounting numbers in a firewall shouldn't be
> > > > trusted, but I won't argue that point since the firewall is often the
> > > > most 'natural' place to stick network accounting software.
> > >
> > > If you can't trust something in the kernel, then you just can't tr
> > > > Again, it's not a fix, it's a feature. Not being able to mess with
> > > > counters (logging or otherwise) is a feature. It may be a feature that
> >
> > > > you can do without, but that decision is not to be made lightly.
> > >
> > > I'm _saying_ to c
> > Again, it's not a fix, it's a feature. Not being able to mess with
> > counters (logging or otherwise) is a feature. It may be a feature that
> > you can do without, but that decision is not to be made lightly.
>
> I'm _saying_ to create a completely separ
> > > I like the ability at secure level 3 to only reset the counters forward..
> > > It fits in with such things as the "append only" flag.
> >
> > Then we'd have to implement per-rule counters that default to
> > IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very
> > diffe
> > > > One could argue that accounting numbers in a firewall shouldn't be
> > > > trusted, but I won't argue that point since the firewall is often the
> > > > most 'natural' place to stick network accounting software.
> > >
> > > If you can't trust something in the kernel, then you just can't t
> > (Another thing I just thought of is that this could cause DoS attacks on
> > the system if a user compromised root and then set the limit to a very
> > high number.)
>
> If you have someone going berzerk as "root" on a firewall you're definitely
> going to have a completely different set of he
> > How do you figure? Currently, the kernel will quit 'logging' denied
> > packets when the counter reaches a specific (compiled-in) number.
> ^
> Then what is
>
> net.inet.ip.fw.verbose_limit: 0
Well I'll be. You learn something new ev
> Peter Jeremy writes:
> > > If it ever gets
> > >committed (I don't think it's particularly useful myself),
> > That's 2 against, 1 (me) for.
>
> Three against.
4 against.
Nate
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
> ipfw allows you to clear counters. It is a feature that already exists.
>
> However, it does not allow you to do it if you are sitting at secure
> level 3.
>
> Why not? I can't think of any good reason why clearing the counters
> should be disallowed when sitting at a hig
> I like the ability at secure level 3 to only reset the counters forward..
> It fits in with such things as the "append only" flag.
Then we'd have to implement per-rule counters that default to
IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very
different setup than what we c
> :That doesn't mean we shouldn't allow people to have an unsophisticated setup,
> :just because a sophisticated one is available. It would be useful to have
> :a per-firewall-rule counter, decrement it on each match if logging and
> :set, and be able to reset to something higher.
> :
> : Brian Fun
> :Instead of zeroing it, how about raising the logging limit to (current +
> :whatever the limit was)
> :
> : Brian Fundakowski Feldman _ __ ___ ___ ___ ___
> : gr...@freebsd.org _ __ ___ | _ ) __| \
>
> The way I see it either some piece of software is monit
> > (Another thing I just thought of is that this could cause DoS attacks on
> > the system if a user compromised root and then set the limit to a very
> > high number.)
>
> If you have someone going berzerk as "root" on a firewall you're definitely
> going to have a completely different set of h
> > You get *better* information on per-rule limits than on a global limit.
>
> No, you simply get a finer-grained ability to select.
Which is almost always better.
> > > If I'm an admin, I'm going to think "Well lets see, I want to store a
> > > month of bad packets in it.
> >
> > If you're an
> > How do you figure? Currently, the kernel will quit 'logging' denied
> > packets when the counter reaches a specific (compiled-in) number.
> ^
> Then what is
>
> net.inet.ip.fw.verbose_limit: 0
Well I'll be. You learn something new e
> Peter Jeremy <[EMAIL PROTECTED]> writes:
> > > If it ever gets
> > >committed (I don't think it's particularly useful myself),
> > That's 2 against, 1 (me) for.
>
> Three against.
4 against.
Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body
> ipfw allows you to clear counters. It is a feature that already exists.
>
> However, it does not allow you to do it if you are sitting at secure
> level 3.
>
> Why not? I can't think of any good reason why clearing the counters
> should be disallowed when sitting at a hi
> I like the ability at secure level 3 to only reset the counters forward..
> It fits in with such things as the "append only" flag.
Then we'd have to implement per-rule counters that default to
IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very
different setup than what we
> :That doesn't mean we shouldn't allow people to have an unsophisticated setup,
> :just because a sophisticated one is available. It would be useful to have
> :a per-firewall-rule counter, decrement it on each match if logging and
> :set, and be able to reset to something higher.
> :
> : Brian Fu
> :Instead of zeroing it, how about raising the logging limit to (current +
> :whatever the limit was)
> :
> : Brian Fundakowski Feldman _ __ ___ ___ ___ ___
> : [EMAIL PROTECTED] _ __ ___ | _ ) __| \
>
> The way I see it either some piece of software is moni
> > You get *better* information on per-rule limits than on a global limit.
>
> No, you simply get a finer-grained ability to select.
Which is almost always better.
> > > If I'm an admin, I'm going to think "Well lets see, I want to store a
> > > month of bad packets in it.
> >
> > If you're a
> > > Having a per-rule limit means that you
> > > actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log"
> > > limit
> > > (assuming an attacker exploits multiple rules) rather than a limit of
> > > "IPFW_VERBOSE_LIMIT".
> >
> > I disagree. I have *tons* of firewall rules, and I
> > > Having a per-rule limit means that you
> > > actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" limit
> > > (assuming an attacker exploits multiple rules) rather than a limit of
> > > "IPFW_VERBOSE_LIMIT".
> >
> > I disagree. I have *tons* of firewall rules, and I don't
> > :So, I've a box that I have an ipfw ruleset on. The firewall should not be
> > :changeable during runtime, and the box runs at securelevel=3.
> > :
> > :In order to prevent DoS disk-fill attacks, I also have specified
> > :IPFW_VERBOSE_LIMIT.
FWIW, as you pointed out below, this was put in sp
> > :So, I've a box that I have an ipfw ruleset on. The firewall should not be
> > :changeable during runtime, and the box runs at securelevel=3.
> > :
> > :In order to prevent DoS disk-fill attacks, I also have specified
> > :IPFW_VERBOSE_LIMIT.
FWIW, as you pointed out below, this was put in s
> > > > LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid
> > > > executables
> > > > in FreeBSD.
> > >
> > > But the point being made is that they are not ignored for executables
> > > which have no read access. And from there, read access can be gained,
> > > because at that poin
> > LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid executables
> > in FreeBSD.
>
> But the point being made is that they are not ignored for executables
> which have no read access. And from there, read access can be gained,
> because at that point, you have code running in the p
> > > > LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid executables
> > > > in FreeBSD.
> > >
> > > But the point being made is that they are not ignored for executables
> > > which have no read access. And from there, read access can be gained,
> > > because at that point, you h
> The PR proposes (and the patch given earlier implements) tighter
> security on the premise that security in the presence of KTRACE
> should be at least as tight as without KTRACE. It achieves this
> by requiring read permissions on an executable before it can be
> KTRACE'd.
As other have pointe
> jk> The intent of this change is to prevent a user from seeing how an
> jk> executable with '--x--x--x' perms works by ktrace'ing its execution.
>
> jk> My question to -hackers is: is this a useful semantic? Would it break
> jk> anything if added?
>
> nw> If we make kernel auditing based upo
> > LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid executables
> > in FreeBSD.
>
> But the point being made is that they are not ignored for executables
> which have no read access. And from there, read access can be gained,
> because at that point, you have code running in the
> The PR proposes (and the patch given earlier implements) tighter
> security on the premise that security in the presence of KTRACE
> should be at least as tight as without KTRACE. It achieves this
> by requiring read permissions on an executable before it can be
> KTRACE'd.
As other have point
> jk> The intent of this change is to prevent a user from seeing how an
> jk> executable with '--x--x--x' perms works by ktrace'ing its execution.
>
> jk> My question to -hackers is: is this a useful semantic? Would it break
> jk> anything if added?
>
> nw> If we make kernel auditing based up
>
> PR bin/3546 asks that `ktrace(1)' not be allowed on files that do not have
> read permissions for the user attempting to execute them.
>
> The intent of this change is to prevent a user from seeing how an
> executable with '--x--x--x' perms works by ktrace'ing its execution.
>
> My questio
>
> PR bin/3546 asks that `ktrace(1)' not be allowed on files that do not have
> read permissions for the user attempting to execute them.
>
> The intent of this change is to prevent a user from seeing how an
> executable with '--x--x--x' perms works by ktrace'ing its execution.
>
> My questi
> :Returning NULL isn't an error, it's an indication that there is no more
> :memory. Don't think if it as an error, think of it as a hint.
>
> It's only a hint if it is returned due to the process resource limit
> being hit. If it is returned due to the system running out of swap,
>
> :Most of the work we've done wouldn't allow this, especially if we were
> :using an OS like FreeBSD with a fairly long bootup time. Especially if
> :it can be avoided.
> :
> :Yes, we could (and did) do our own memory management, but it seems to me
> :that the kernel has alot more information ava
> :> > Quite true. In the embedded world we preallocate memory and shape
> :> > the programs to what is available in the system. But if we run out
> :> > of memory we usually panic and reboot - because the code is designed
> :> > to NOT run out of memory and thus running out of me
[ Trimmed CC list a bit ]
> > :* even if you are not willing to pay that price, there _are_ people
> > :who are quite willing to pay that price to get the benefits that they
> > :see (whether it's a matter of perception or not, from their
> > :perspective they may as well be real) of such a scheme
> :Returning NULL isn't an error, it's an indication that there is no more
> :memory. Don't think if it as an error, think of it as a hint.
>
> It's only a hint if it is returned due to the process resource limit
> being hit. If it is returned due to the system running out of swap,
>
> :Most of the work we've done wouldn't allow this, especially if we were
> :using an OS like FreeBSD with a fairly long bootup time. Especially if
> :it can be avoided.
> :
> :Yes, we could (and did) do our own memory management, but it seems to me
> :that the kernel has alot more information av
> :> > Quite true. In the embedded world we preallocate memory and shape
> :> > the programs to what is available in the system. But if we run out
> :> > of memory we usually panic and reboot - because the code is designed
> :> > to NOT run out of memory and thus running out of m
[ Trimmed CC list a bit ]
> > :* even if you are not willing to pay that price, there _are_ people
> > :who are quite willing to pay that price to get the benefits that they
> > :see (whether it's a matter of perception or not, from their
> > :perspective they may as well be real) of such a schem
> > > We're adding some machines at work for (essentially) cgi
> > > processing only. It was never considered to use anything less than 2 cpu
> > > boxes, and the current round of testing is going so well that we're
> > > seriously considering 4 cpu boxes because they are not that much more
> > >
> | I know of *NO* programmer who does not delight in completely ripping out
> | and replacing existing code with code that he has written from scratch.
> | It's great fun, and it allows the person to feel better about the
> | system, themselves, and make sure that they can debug the existing code
[
None of the below is assumed to be taken as reflecting any situation
that occurred in FreeBSD. This is a *common* problem that exists in
every software program, and any reflection on what happened in FreeBSD
is by coincedence in that it's a software program. My comments apply
as easi
[
Some history: I'm not a core member (I gave that up responsibility years
ago), but I was one of the three weirdo's that started up FreeBSD back
when I had no life. My opinions are my own, and don't reflect the core
team. I don't know the exact reasons why the core team removed Matt's
commit pri
> : [ gps talk ]
> :...
>
> I've been very impressed with the newer ( last 5 months ) Garmin
> handhelds. The older ones only had 8 channel receivers. The newer
> ones have 12 channel receivers sensitive enough that the units often
> work indoors.
FWIW, the Garmin 12XL is a *ve
> For people who have idle cpu to spare, this is a good time to start
> putting those cycles to good use with the Seti project!
Where would would find informatio on said project?
Nate
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of t
> Is it possible to change the mac address of an ethernet card using
> ifconfig?
Not in any 'standard' card, no. Some cards (in SUN workstations) allow
you to swap the EEPROM with the mac address, and I'll bet somewhere
someone has designed a card with a programmable mac address, but
normally it
> -
> and here's the ld line for the shared object I am loading;
>
> ld -Bshareable -o $@ $< -u _floor ../../lib/libV.a
> /usr/local/lib/mysql/libmysqlclient.a /usr/lib/libm.a
This is probably unrelated to the bug (but it might be related).
201 - 278 of 278 matches
Mail list logo
