On Sun, Dec 11, 2011 at 4:29 PM, John Tate <[email protected]> wrote: > > > On Mon, Dec 12, 2011 at 7:47 AM, Andres Perera <[email protected]> wrote: >> >> On Sun, Dec 11, 2011 at 3:29 PM, John Tate <[email protected]> wrote: >> > I am not replying to every thread on the list. You either have me >> > confused >> > with someone else or there is some kind of imposter or person with a >> > similar name. I'm confused I should say. This was something constructive >> > to >> > say regardless, it was an idea. I remember last time I was using OpenBSD >> > (I >> > had a hiatus) and mmap changes broke a lot of ports. There is supposed >> > to >> > be an emphasis on security, not your scripts. OpenBSD warns about >> > mistakes, >> > it emails you about your mistakes, and it could point out this mistake >> > as >> > well. >> >> not having "block" as default isn't really a mistake, unless pfctl can >> read your mind >> >> if you don't have daemons listening then what's the point of blocking >> ports? > > If you don't have deamons listening then why the hell are you using an > operating system with so much security on networks.
because i might be a desktop user i use obsd on my main machine and a netbook the netbook normally doesn't have any daemons listening outside localhost, but i still use pf for other reasons, such as managing routing domains pf has queue and logging functions aswell... not every config is going to center around acl even for those that have daemons facing hostile networks, their admins may choose a black list policy instead >> >> >> just an example of many situations that could occur >> >> > >> > On Mon, Dec 12, 2011 at 5:55 AM, James Shupe <[email protected]> wrote: >> > >> >> No. Modifying a general purpose tool for a specific (albeit common) use >> >> case is stupid. Any properly implemented warning would cause pfctl to >> >> exit non-zero, which would break automated scripts that check the exit >> >> code of pfctl. You would have to add a whole new option to ignore your >> >> specific use case, and even that would require modifying existing >> >> scripts. >> >> >> >> I wish they would ban you from this list already. I'm sick of seeing >> >> your reply to every thread when you never have anything constructive to >> >> say. >> >> >> > >> > I am not replying to every thread on the list. You either have me >> > confused >> > with someone else or there is some kind of imposter or person with a >> > similar name. I'm confused I should say. This was something constructive >> > to >> > say regardless, it was an idea. I remember last time I was using OpenBSD >> > (I >> > had a hiatus) and mmap changes broke a lot of ports. There is supposed >> > to >> > be an emphasis on security, not your scripts. OpenBSD warns about >> > mistakes, >> > it emails you about your mistakes, and it could point out this mistake >> > as >> > well. >> > >> > Perhaps it could be for security(8) to do instead actually. I don't >> > know, I >> > didn't design the fucking system, it was just a suggestion. >> > >> > >> >> On Mon, 2011-12-12 at 05:43 +1100, John Tate wrote: >> >> > It's just whining! Perhaps if should only do it if it has an Internet >> >> > IP >> >> > address not a LAN or WAN one involved. >> >> > >> >> > On Mon, Dec 12, 2011 at 5:17 AM, Janne Johansson <[email protected] >> >> >wrote: >> >> > >> >> > > 2011/12/11 John Tate <[email protected]> >> >> > > >> >> > >> >> >> > >> So I have a suggestion worth considering, if the line "block in >> >> > >> all" >> >> does >> >> > >> not appear pfctl -nf should perhaps spit out a warning. Much like >> >> you've >> >> > >> done with your pretty compilers over there. >> >> > >> >> >> > >> >> >> > > There are still lots of reasons to run PF even if you don't want >> >> "block in >> >> > > all" for a default, so whining on all the other uses you couldn't >> >> imagine >> >> > > would not be very productive. >> >> > > >> >> > > -- >> >> > > B To our sweethearts and wives. B May they never meet. -- 19th >> >> > > century >> >> toast >> >> >> >> >> > >> > >> > -- >> > www.johntate.org >> > > > > > > -- > www.johntate.org
