lkml.org 
[lkml]   [2000]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectIP filtering should default to DENY?
On Mon, 17 Jan 2000, Eric Preston wrote:

This is posted to linux-kernel because I do not have POSIX, etc..
documents handy to provide pure facts, but I know other people
do. Also, I figured others would have a better job in squashing
the thread quickly - either way, and with a lot more valid points
than I could.

The thread is based on a message I wrote claiming that the boot
sequence in RedHat brings up network interfaces prior to
linuxconf enabling firewall rules thus giving a window of
opportunity at boot time at which the firewall is not enabled. I
suggested that the firewall scripts should be called PRIOR to
networking.

Next, it was suggested that the kernel's source be modified to
change the default rules to DENY instead of accept. I did not
see any reason for this since the same can be achieved in
userland without editing source, just by putting the ipchains
script ahead of the one that enables network interfaces.

This now brings up a debate that the kernel would be more secure
if it defaulted to DENY which I disagree with, and believe that
it would likely violate POSIX or UNIX98 or some other standard.
I do not have any specific info to support this, but I'll bet
someone else does know and can set things straight.

So, what is the reason for the ipfilter defaulting to ACCEPT?
(Aside from the fact that it doesn't matter, and can be done in
userland quite effectively that is... ;o)

----

>> No, that would violate POSIX, and possibly UNIX98 or other
>> standards (although I can't offer a particular example).
>
>Frankly I don't believe you. How would that violate POSIX or UNIX98, can
>you point me to where this is stated? You're telling me that POSIX or
>UNIX98 defines default firewalling policy?

I was speaking non-authoritatively and thought that was clear,
but perhaps not.

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.

I would put my money that POSIX or UNIX98 or some other standard
that we are aiming for compliance with also details the default
ip filter policy. Someone else can confirm or deny this. Either
way, it is pointless because putting policy in kernel is not our
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.

>Even if it does, breaking a recommendation for security seems like a good
>idea to me.

No it does not. There would be no increase in security. When
the Linux kernel boots up, there are NO NETWORKING INTERFACES
activated. Regardless of what the IP filter's default policies
are, there is NO NETWORKING so NO effectively the kernel doesn't
pass any packets - because there are not any, and can't be UNTIL
the networking interfaces are activated. There isn't even a
loopback interface until it is activated.

That stated, as long as the init sequence activates the
firewalling scripts PRIOR to network interfaces coming up, there
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.


>> 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.


>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...


>Go look at the code. I believe the most relevent piece is in
>net/core/firewall.c, in the bottom __initfunc function in the assignment
>== FW_ACCEPT. Modifying the initial state of the firewalling code requires
>modifying the c source and rebuilding the kernel. This is not a 100%
>userland possible task. It's a 100% userland impossible task. As outlined
>below it's not even 100% safe in all circumstances.

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
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
be done securely and safely from userland, then it should exist
there. The fact that a system can be ran by an idiot that puts
things in the wrong order is not the problem of the kernel
source. Hire an admin that is not an idiot and check the
configuration to ensure firewall rules come before networking is
not a lot to ask. The kernel's job is not to "hand hold".

>Make it default DENY or REJECT and then no
>distribution-maker/userland-app-writer could decide to open the system up
>by accident, regardless of the order of scripts and bring up of
>interfaces. You'd have to have a poorly written firewall ruleset to open
>things wide open.

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.

>This makes the most sense. Stop the problem at the most effective point.

The most effective way is the way it is now.

>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.

>> The kernel boots up with default
>> policy of ACCEPT. This is harmless because NO interfaces are
>> configured yet. A firewall script runs and changes the policies
>> as per local configuration, and THEN the interfaces are brought
>> up.
>
>I can think of at least one configuration where it will not be harmless
>given an average situation. Take dynamic assignment of the external
>interface IP number for example. How do you get the external IP for use in
>the firewall ruleset without bringing up the interface?

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
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.

With your proposed solution of enforcing userland policy in
kernel by default, here is what would happen on such a system -
using your own example:

1) Kernel boots up and configures DENY or REJECT on
input/output/forward chains internally.
2) Script runs that attempts to bring up network interface using
DHCP or some other "dynamic assignment" method as you propose.
3) The packets do not go out nor return because ip filtering has
defaulted to disabling all networking.
4) The interfaces fail to come up.

5) The ipfilter script runs and enables filter rules but there
are no interfaces.

Your scenario loses. The proper way to do ANY sort of ip
filtering is to activate the filter rules prior to network
interfaces going up. That includes default policy and rule
overrides. There are cases like DHCP et al that require special
things, but again as I said above, those machines are unlikely to
use ipfiltering anyways, and if they do they are rare cases which
can likely be easily worked around via scripting or manually.


>Once the interface is up, the ACCEPT policy is in effect and
>sure, maybe you got lucky and didn't bring up the internal
>interface yet, but you're still in an default ACCEPT situation.
>If you did, then you're in the aforementioned race condition to
>bring up the appropriate rules. (what you say linuxconf does)

Except that the interface would not COME up because you've
defaulted the kernel to DENY. ;o)

>Anyhow, you do it your way, I'll do it mine. I'll let you know if I figure
>out an ultrafast racecondition exploit... ;-)

Just don't try to use your machine with DHCP. ;o)

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...

Take care,
TTYL

--
Mike A. Harris Linux advocate
Computer Consultant GNU advocate
Capslock Consulting Open Source advocate

Join the FreeMWare project - the goal to produce a FREE program in
which you can run Windows 95/98/NT, and other operating systems.

http://www.freemware.org


-
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/

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