/proc/sys/net/ip*/conf/all/* does not actually affect interfaces

/proc/sys/net/ip*/conf/all/* does not actually affect interfaces

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 2461 bytes --]

Dear kernel gurus,

I was unpleasantly surprised last night that a rogue machine managed
to alter the IPv6 default route of one of my servers, despite my
sysctl configuration, which disables RA for "all" interfaces during
the boot sequence. It also changes the "default" values:

  net.ipv6.conf.default.autoconf = 0
  net.ipv6.conf.default.accept_ra = 0
  net.ipv6.conf.default.accept_ra_defrtr = 0
  net.ipv6.conf.default.accept_ra_pinfo = 0
  net.ipv6.conf.default.accept_source_route = 0
  net.ipv6.conf.default.accept_redirects = 0
  net.ipv6.conf.default.forwarding = 0
  net.ipv6.conf.all.autoconf = 0
  net.ipv6.conf.all.accept_ra = 0
  net.ipv6.conf.all.accept_ra_defrtr = 0
  net.ipv6.conf.all.accept_ra_pinfo = 0
  net.ipv6.conf.all.accept_source_route = 0
  net.ipv6.conf.all.accept_redirects = 0
  net.ipv6.conf.all.forwarding = 0

Yet, net.ipv6.conf.eth0.* values were unchanged, and routing
advertisements honoured.

This also applies to files in ipv4/, e.g. accept_redirects

A bit of investigation shows that something fishy is going on, or
at least it's unexpected to me, because I recall the conf/all/*
interface to do what it promised to do a while ago. Not anymore
though.

seamus# pwd
/proc/sys/net
seamus# head ipv4/conf/{all,eth0}/accept_redirects  
==> ipv4/conf/all/accept_redirects <==
1

==> ipv4/conf/eth0/accept_redirects <==
1
seamus# echo 0 >| ipv4/conf/all/accept_redirects  
seamus# head ipv4/conf/{all,eth0}/accept_redirects  
==> ipv4/conf/all/accept_redirects <==
0

==> ipv4/conf/eth0/accept_redirects <==
1



***** shouldn't ipv4/conf/eth0/accept_redirects be 0 too??


same with ipv6:

seamus# head ipv6/conf/{all,eth0}/accept_ra
==> ipv6/conf/all/accept_ra <==
1

==> ipv6/conf/eth0/accept_ra <==
1
seamus# echo 0 >| ipv6/conf/all/accept_ra
seamus# head ipv6/conf/{all,eth0}/accept_ra
==> ipv6/conf/all/accept_ra <==
0

==> ipv6/conf/eth0/accept_ra <==
1



What is going on? Is this my fault, did something change in the
kernel, or is this a bug?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"in the figure of the president, george w. bush, the incompetence,
 stupidity, and sheer inhumanity that characterize so much of
 america's money-mad corporate elite find their quintessentially
 repulsive expression."
                                 -- journalist, aftermath of katrina
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: /proc/sys/net/ip*/conf/all/* does not actually affect interfaces

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 808 bytes --]

also sprach martin f krafft <madduck@madduck.net> [2009.03.02.1327 +0100]:
> A bit of investigation shows that something fishy is going on, or
> at least it's unexpected to me, because I recall the conf/all/*
> interface to do what it promised to do a while ago. Not anymore
> though.

Sorry for being an idiot and not including the important data: this
happens on Debian kernels 2.6.24-.28 across several machines.
I checked the Debian diff but could not find anything that seems
related, and I reproduced it with 2.6.29-rc6-git5.

Thanks,

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
the security, stability and reliability of a computer system
is reciprocally proportional to
the amount of vacuity between the ears of the admin.
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: /proc/sys/net/ip*/conf/all/* does not actually affect interfaces

[Philipp Matthias Hahn]

Hello!

On Mon, Mar 02, 2009 at 01:27:18PM +0100, martin f krafft wrote:
> I was unpleasantly surprised last night that a rogue machine managed
> to alter the IPv6 default route of one of my servers, despite my
> sysctl configuration, which disables RA for "all" interfaces during
> the boot sequence. It also changes the "default" values:
...
> Yet, net.ipv6.conf.eth0.* values were unchanged, and routing
> advertisements honoured.
> 
> This also applies to files in ipv4/, e.g. accept_redirects
...

As far as I researched for IPv4 some time ago, the "default" value gets
copied to newly created interfaces only once.
"all" on the other hand allways gets applied in addition to the current
setting, but it depends on the exact setting, if its ORed, ANDed, or
whatevered:
	log_martians         OR
	accept_redirects     AND
	forwarding           ?
	mc_forwarding        AND
	medium_id
	proxy_arp            OR
	shared_media         OR
	secure_redirects     OR
	send_redirects       OR
	bootp_relay          AND
	accept_source_route  AND
	rp_filter            AND
	arp_filter           OR
	arp_announce         MAX
	arp_ignore           MAX
	arp_accept
	app_solicit
	disable_policy
	disable_xfrm
	tag
(see include/linux/inetdevice.h:83 for IN_DEV_{AND,OR,MAX}CONF)

Putting a new value in "all" doesn't change the value you read from
"$interface", but it only gets computed and used internally.

BYtE
Philipp
-- 
  / /  (_)__  __ ____  __ Philipp Hahn
 / /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\ pmhahn@titan.lahn.de

Re: /proc/sys/net/ip*/conf/all/* does not actually affect interfaces

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1999 bytes --]

also sprach Philipp Matthias Hahn <pmhahn@titan.lahn.de> [2009.03.03.0800 +0100]:
> "all" on the other hand allways gets applied in addition to the current
> setting, but it depends on the exact setting, if its ORed, ANDed, or
> whatevered:
[...]

Oh wow. This is very underdocumented. Thanks Philipp for taking the
time to reply!

The only reference I could find was

  http://lkml.indiana.edu/hypermail/linux/kernel/0103.0/0440.html

which was unanswered.

Can anyone recall the rationale for this somewhat complex-seeming
solution?

I suppose the goal is to allow all/* to override (which would be the
right solution). However, it depends on whether the default is 0 or
1 on whether to AND or OR. Example:

> 	log_martians         OR

default off, to turn it on globally, I just need to set all=1 and
the OR takes care of it.

> 	rp_filter            AND

default on, but to disable it globally (set all=0), it needs the
AND.

> (see include/linux/inetdevice.h:83 for IN_DEV_{AND,OR,MAX}CONF)

Unfortunately, that's just ipv4/conf/* and I cannot seem to find the
ipv6/conf/* counterparts.

> Putting a new value in "all" doesn't change the value you read
> from "$interface", but it only gets computed and used internally.

Hm, that clears it up... kinda. It does *not* explain by the RAs
were still accepted (ipv6.conf.all.accept_ra and .autoconf where
both 0), so unless those values are (wrongly) OR'd, I will need to
investigate this.

I will also work on patches to fix the documentation of this, and
that involves the kernel source as well as e.g. the IPv6 HOWTO and
other docs and manpages.

But to do this, I'd really like to know a bit more about the design
motivation. Anyone?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
before he died, rabbi zusya said: "in the world to come they will not
ask me, 'why were you not moses?' they will ask me, 'why were you not
zusya?'"
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: /proc/sys/net/ip*/conf/all/* does not actually affect interfaces

[Philipp Matthias Hahn]

Hello Martin!

On Tue, Mar 03, 2009 at 08:27:47PM +0100, martin f krafft wrote:
> also sprach Philipp Matthias Hahn <pmhahn@titan.lahn.de> [2009.03.03.0800 +0100]:

> > Putting a new value in "all" doesn't change the value you read
> > from "$interface", but it only gets computed and used internally.
> 
> Hm, that clears it up... kinda. It does *not* explain by the RAs
> were still accepted (ipv6.conf.all.accept_ra and .autoconf where
> both 0), so unless those values are (wrongly) OR'd, I will need to
> investigate this.

I took another look at
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/linux/inetdevice.h;hb=HEAD#l102

102 #define IN_DEV_RX_REDIRECTS(in_dev) \
103         ((IN_DEV_FORWARD(in_dev) && \
104           IN_DEV_ANDCONF((in_dev), ACCEPT_REDIRECTS)) \
105          || (!IN_DEV_FORWARD(in_dev) && \
106           IN_DEV_ORCONF((in_dev), ACCEPT_REDIRECTS)))

"accept_redirect" depends on "forwarding": If forwarding is enabled,
it's ANDed, if it's disabled, it's ORed.

> > "all" on the other hand allways gets applied in addition to the current
> > setting, but it depends on the exact setting, if its ORed, ANDed, or
> > whatevered:
> [...]
> 
> Oh wow. This is very underdocumented.

Yes, I only can agree with you.

BYtE
Phhilipp Hahn
-- 
  / /  (_)__  __ ____  __ Philipp Hahn
 / /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\ pmhahn@titan.lahn.de