I'll start off by saying that I never would have thought that such an
offhand discussion on my part would make itself to the level of
unfortunate time-wasting on the kernel list, I'll apologize and state that
I'm not planning on continuing this thread (much), sufficed to say in
french: chacun son gout (english: to each their own)
> >> No, that would violate POSIX, and possibly UNIX98 or other
> >> standards (although I can't offer a particular example).
>
> I was speaking non-authoritatively and thought that was clear,
> but perhaps not.
It was quite clear, hence my request for a citation, if possible. I think
someone else has already provided one to RFCs.
> A while back, Linux enabled ip_forward by default (again, unless
> I am mistaken). This was NON-POSIX behaviour I believe, and
> it was changed to default to turn off forwarding by default.
Is is my imagination or is ip_forward on, on redhat 6.1 dist by default? I
can't remember.
> goal. Things that can be done safely and securely from userland
> - should be. Not in kernel just for the sake of it, or for
> security through obscurity.
Uhm, this wouldn't be an issue of security through obscurity, that's a
little hard with FS/Open Source. '/sbin/ipchains -L' is hardly a secret,
nor is 'less net/core/firewall.c'. Sorry, this is just a cheap shot.
> That stated, as long as the init sequence activates the
> firewalling scripts PRIOR to network interfaces coming up, there
"As long as..." that's the crux, eh. My original message indicated that in
my situation I have to bring up the external interface to get it's IP,
then build my ruleset.
> is NO security problem. Local policy issues are NOT things that
> should EVER go into the kernel. There is absolutely no increase
> in security by putting policy in the kernel.
To tell you the truth, I'm going to defer to the immanent (eminent?)
experts on this list and try to avoid saying what should and shouldn't go
into the kernel.
My original comment was something along the lines of, "that perhaps the
truly paranoid might want to do something like that..." I don't remember
suggesting petitioning the powers-that-be to make this change anywhere
except possibly on my own system.
> >> Changing the kernel's default policy is pointless. It can be
> >> done in userland 100% safe.
> >
> >It's not pointless.
>
> It is pointless. If it was not, then Linus, Alan, or someone else
> would have done so allready. I do not want to argue with you
> about it because even that is pointless.
You're doing a good job of not arguing about pointless.
I'm gonna just drop it.
> >If the ipchains default policy configuration was input, output, forward ==
> >DENY by default, something like linuxconf couldn't bring up the interfaces
> >then the rules while leaving things wide open in the middle.
>
> Not everyone runs a firewall. The kernel should not enforce
> things in itself that are easily done in userland. IP filter
> configuration is easily done in userland - by having an
> administrator put their scripts in the proper order - which
> RedHat does not. I suppose you'd also like to see the kernel
> default to a higher securelevel so that root can't change
> immutable files too. It would be more secure that way...
> Pointless...
On reflection, it seems that perhaps anything except default forward =
DENY might be a little silly (paranoid?), but then again, you can always
work around this by, as you put it, ordering your initscripts properly in
userspace and a couple of ipchains commands.
> No. If there are no active network interfaces at boot time, then
> there is NO WAY for ANY PACKETS to enter the machine PERIOD. The
> init scripts can change the firewall policy first to DENY/REJECT,
> enable the ACCEPT rules that override, and THEN bring up network
My whole point from the beginning is that it's hard to build your firewall
ruleset and load them before bringing up an interface on a DHCP system
(I've setup a handful of home cable/adsl firewall systems, granted perhaps
this is uncommon) without first bringing up an interface to get today's IP
number. At no time did I suggest packets were magically appearing out
of thin air. You're beating this dead horse and it's getting smelly.
> interfaces. Extending your logic, we should build "init" into
> the kernel, and all of the rest of the initscripts that modify
> default system policy in some way related to security. If it can
Please don't put such inane comments in *my* mouth.
> not a lot to ask. The kernel's job is not to "hand hold".
See previous comment re:appropriate personnel for kernel-responsibility
decision-making...
> And you'd also have to have ipchains installed on every system,
> including ones that have no need for ip filtering - just to
> re-enable networking.
Valid point. Less systems if only default forwarding is DENY, correct?
> >Why waste your time tracking down this particular distributions sequence
> >of startup scripts? Maybe a different distribution is different, I think
> >you can fix it for all of them this way.
>
> And then you will require that every system requires ipchains,
> including boot floppies, and also that joe user knows how to
> re-enable the networking. What you are proposing is effectively
> "totally disabling networking" in kernel, and requiring a
> userland tool to re-enable it.
I'm just gonna ignore this. I'd like to strike previous questions about
suggesting anyone do anything, particularly you Mike.
> Such machines are often laptops or some other system using DHCP
> or similar, and is *HIGHLY* unlikely to be a server, or running
> an ip firewall to begin with. If the ipchains script executed
I've got nothing but boxes like this. None of them are laptops (somebody
can send me a nice one if they like, I'd like to get a FreeS/WAN
roadwarrior setup going ;-) Anyway, I'm not gonna pretend I know the
*average* setup, my sample size is too small.
> prior to networking going up it could test for DHCP or similar
> being used - by examining files in sysconfig for example, and
> could enable only what needs to be enabled in order for DHCP to
> work, then enable full firewalling later. At any rate such a
> system would be an extreme rarity.
One man's potato is another man's potato. Rare to you,
common to me. But I digress...
Anyway, I can't be bothered to go on responding to your message, you're
the one who forwarded this to the list, and I'm willing to guess that
everyone'd be just as happy if I dropped this packet^H^H message on the
floor right here.
[... much deleted ...]
> Sorry for the long post people, but I would like to see how
> experienced kernel folk think about changing default policy like
> this. Perhaps it is I that is wrong, and something that I am
> overlooking.... I think that if that was the case though, it
> would have been changed a LONG time ago...
Unable to connect to remote host: Connection refused
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:17 EST