netdev - Re: [PATCH]: Add Network Sysrq Support

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:	Wed, 22 Jun 2011 13:37:17 +0100
From:	John Haxby <john.haxby@...cle.com>
To:	Florian Westphal <fw@...len.de>
CC:	Prarit Bhargava <prarit@...hat.com>,
	David Miller <davem@...emloft.net>, fbl@...hat.com,
	netdev@...r.kernel.org, agospoda@...hat.com, nhorman@...hat.com,
	lwoodman@...hat.com
Subject: Re: [PATCH]: Add Network Sysrq Support

On 22/06/11 11:54, Florian Westphal wrote:
> Prarit Bhargava <prarit@...hat.com> wrote:
>
> [ cc'd John Haxby, who worked on xt_SYSREQ ]
>
>> On 06/21/2011 06:58 PM, David Miller wrote:
>>> From: Florian Westphal <fw@...len.de>
>>> Date: Wed, 22 Jun 2011 00:56:45 +0200
>>>> This is one of the reasons why I still think that
>>>> xt_SYSREQ would be the better solution, you get all
>>>> kinds of filtering features for free.
>>>>
>>>> You could even use crazy things like '-m time' to restrict
>>>> sysreq availability to working hours and whatnot.
>>>>
>>> Agreed.
>> Using the netfilter xt-SYSRQ code seems to store the entered code and
>> execute it later after the system has returned to a normal state....
>> which is much too late to be useful.
> The target handler of the kernel part invokes handle_sysrq(),
> I don't see any delaying/queueing?
>
> FWIW, the old discussion is in the archives:
> search for subject "nf-next: sysrq and condition 20100421" from Jan
> Engelhardt, or try
> http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/33615/focus=34808
>
> As far as i understand the use case described by John Haxby matches yours.
>
> Patrick McHardy suggested an alternative standalone method involving
> encapsulation sockets; perhaps the reasons why this path was not chosen
> have changed.
>
> I think that a standalone module (i.e. not requiring netfilter) that
> runs the sysreq handling after all netfilter hooks would be optimal,
> but I don't see a simple method to implement that.

The xt_SYSRQ calls handle_sysrq() in BH context, much the same context
as ping is handled in.  (Actually, it's likely xt_SYSRQ will work even
if ping doesn't since nothing has to come back.)

It's possible for xt_SYSRQ to fail.   My usual case for failure was
simply not enabling it :-)  However, as you typically have to fight your
way through iptables to get to xt_SYSRQ then you can get into trouble
that way.

Although I wasn't sure that it could happen, it's also possible that the
cryptographic functions can get in your way.  xt_SYSRQ does its best to
avoid problems by pre-allocating everything it can so there is as little
as possible to do when it is needed, but it is possible for it to fail.

The module that Patrick McHardy suggested works up to a point:
handle_sysrq() can still be called in BH context but unfortunately I
couldn't get it working for IPv6: the necessary hook isn't implemented
for IPv6 (or rather, it wasn't, I don't know if something has changed
since then).

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