netdev - Re: [PATCH] net: Remove a noisy printk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 15 Dec 2008 13:23:08 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>
CC:	Jan Engelhardt <jengelh@...ozas.de>,
	David Miller <davem@...emloft.net>, ajax@...hat.com,
	linux-kernel@...r.kernel.org, davej@...hat.com,
	netdev@...r.kernel.org, netfilter-devel@...r.kernel.org
Subject: Re: [PATCH] net: Remove a noisy printk

Jozsef Kadlecsik wrote:
> On Sun, 14 Dec 2008, Jan Engelhardt wrote:
> 
>>> In a >normal< system one usually does not use raw sockets. So if a root 
>>> process do use raw socket, at least netfilter sends a notification and 
>>> there's a chance that someone take notice it by checking the kernel logs.
>>> [...]
>>> But should we remove them due to nuisances on >test< systems?
>>>
>>> Rather make it a kernel compile option but do not remove.
>> This warning is in the conntrack calling code. Iff you play with
>> raw sockets and do something wrong, the generic network code
>> should barf IMHO, not nf_conntrack, and not [nf_conntrack_ipv4 only].
> 
> It is not about doing something wrong at using raw sockets - it's about 
> using raw sockets.
> 
> I'm not quite convinced the generic network code should warn about raw 
> sockets. I believe it belongs to the security-related subsystems - 
> netfilter and (or) the security frameworks. [But as netfilter is much more 
> widely used, the 'or' is just theoretical.)

I agree that it doesn't belong to the generic networking code.
But the way its handled in netfilter is far from perfect as well.
Currently multiple modules will spam the ringbuffer repeatedly,
but offer no possibility to change anything in the behaviour of
how these packets are treated. Unfortunately we can't handle this
in the ruleset (which is exactly the reason why we're spamming
the ringbuffer), so how about we add a module option controlling
how to treat those packets and remove the printk?

In the case of conntrack I would even argue that the message
makes no sense at all since tracking doesn't matter as long as
the state isn't used. And for that the table code can warn or
offer controls.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html