Re: [PATCH]: Add Network Sysrq Support

On 22/06/11 11:54, Florian Westphal wrote:

Prarit Bhargava [off-list ref] wrote:

[ cc'd John Haxby, who worked on xt_SYSREQ ]

quoted

On 06/21/2011 06:58 PM, David Miller wrote:

quoted

From: Florian Westphal <fw@strlen.de>
Date: Wed, 22 Jun 2011 00:56:45 +0200

quoted

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