Date:	Wed, 28 Apr 2010 15:43:30 +0100
From:	John Haxby <john.haxby@...cle.com>
To:	Jan Engelhardt <jengelh@...ozas.de>
CC:	Patrick McHardy <kaber@...sh.net>,
	Netfilter Developer Mailing List 
	<netfilter-devel@...r.kernel.org>,
	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [PATCH 1/2] netfilter: xtables: inclusion of xt_SYSRQ

On 21/04/10 14:35, Jan Engelhardt wrote:
> On Wednesday 2010-04-21 15:17, Patrick McHardy wrote:
>    
>> Jan Engelhardt wrote:
>>      
>>> On Wednesday 2010-04-21 14:59, Patrick McHardy wrote:
>>>
>>>        
>>>> Jan Engelhardt wrote:
>>>>          
>>>>> The SYSRQ target will allow to remotely invoke sysrq on the local
>>>>> machine. Authentication is by means of a pre-shared key that can
>>>>> either be transmitted plaintext or digest-secured.
>>>>>            
>>>> I really think this is pushing what netfilter is meant for a bit
>>>> far. Its basically abusing the firewall ruleset to offer a network
>>>> service.
>>>>
>>>> I can see that its useful to have this in the kernel instead of
>>>> userspace, but why isn't this implemented as a stand-alone module?
>>>> That seems like a better design to me and also makes it more useful
>>>> by not depending on netfilter.
>>>>          
>>> That sort of diverts from the earlier what-seemed-to-be-consensus.
>>>
>>> Oh well, I would not mind holding the single commit up as long as the
>>> rest isn't blocked too :-)
>>>        
>> Then lets skip this one for now.
>>      
> Well you raised the concern before -- namely that kdboe would have
> the very same feature. And yet, kdboe was not part of the kernel.
> Neither is the magical stand-alone module.
> I really prefer to have it in rather than out, because I know
> that's going to mess up maintenance-here-and-there. I'm already
> having a big time with xtables-addons that still carries
> xt_condition and SYSRQ for a while, and it does have some different
> code lines than the kernel copy.
>    

I have to agree with Jan here, but I'd like to raise some additional points.

kdboe (or kgdboe) isn't part of the kernel and I don't think it 
necessarily fits all the use cases for xt_SYSRQ.  The one I have in mind 
is where there is a non-kernel hacker whose machine has got into 
trouble.  The poor harrassed sys admin (in this case) has configured 
netconsole and knows that sysrq-t and sysrq-m are useful as a first 
attempt at passing useful information to someone who knows what might be 
going on and that sysrq-c to get a crash dump will also be useful.   
(This represents quite a few of the better sys admins that I come 
across.)   xt_SYSRQ is likewise easy to set up and easy to use.   It's 
true that k(g)dboe would provide this kind of information provided that 
the debuginfo was present on the target machine and the environment was 
such that any sort of debugging over netconsole was sufficiently secure 
... (is it at least as secure as the xt_SYSRQ controls?)

I was running over the design of a standalone module in my head on the 
way in this morning.   It seems fairly straightforward, but as I started 
adding in necessary requirements like limited IP addresses (which I know 
are not actually secure), limited interfaces (which are more secure in a 
controlled physical environment), user-space control and so on the more 
it was sounding as though it would just be a cut-down iptables.   And 
then, of course, that begs the question "why don't you leave all that 
extra stuff to iptables?"

My own interest in getting xt_SYSRQ into the mainline kernel is that it 
would then be easier to get it accepted in production kernels where it 
would make the poor beleaguered sys admin's life a little easier.  That 
is, _some_ useful information or even a crash dump could be extracted 
from the machine before it's big red button time.

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

Powered by blists - more mailing lists