Whither xt_SYSRQ?

Whither xt_SYSRQ?

[John Haxby]

The earlier discussions about whether to include xt_SYSRQ in mainline 
seem to have petered out with no clear consensus.  As I recall, there 
were two suggestions as an alternative: use k(g)dboe and use a dedicated 
standalone module.

The former suggestion, kdboe, doesn't seem to fly because it's not in 
the kernel and also (unless I'm mistaken) provides little or no 
concession to security.  It's great for development but in the case 
where xt_SYSRQ can be used in a production environment, it doesn't seem 
to work.  Providing the environment for the debugger to work in is also 
likely to involve installing a lot on a production machine that wouldn't 
normally be there.  (xt_SYSRQ is nice and light and would sit nicely 
alongside, for example, netconsole.)

The standalone module is troublesome.  If I was starting from scratch 
with that I'd be putting in filters and whatnot that match those 
provides by xtables anyway.  If everything apart from the actual 
function (sysrq) and password control is duplicated by xtables then 
you'd have to ask "why isn't this part of xtables?".

I know xt_SYSRQ is used by quite a few people and it is seen as 
generally useful, so what needs to be done to get this into the mainline 
kernel?  Once it's there it stands a good chance of being backported to 
some of the production kernels (RHEL6, I'm looking at you) but without 
having some upstream commitment that seems a distant dream.

if xt_SYSRQ isn't acceptable, what is?  (Bearing in mind that I believe 
that whatever it is needs to be acceptable to a production environment.)

jch

Re: Whither xt_SYSRQ?

[Patrick McHardy]

John Haxby wrote:
> 
> The earlier discussions about whether to include xt_SYSRQ in mainline
> seem to have petered out with no clear consensus.  As I recall, there
> were two suggestions as an alternative: use k(g)dboe and use a dedicated
> standalone module.
> 
> The former suggestion, kdboe, doesn't seem to fly because it's not in
> the kernel and also (unless I'm mistaken) provides little or no
> concession to security.  It's great for development but in the case
> where xt_SYSRQ can be used in a production environment, it doesn't seem
> to work.  Providing the environment for the debugger to work in is also
> likely to involve installing a lot on a production machine that wouldn't
> normally be there.  (xt_SYSRQ is nice and light and would sit nicely
> alongside, for example, netconsole.)
> 
> The standalone module is troublesome.  If I was starting from scratch
> with that I'd be putting in filters and whatnot that match those
> provides by xtables anyway.  If everything apart from the actual
> function (sysrq) and password control is duplicated by xtables then
> you'd have to ask "why isn't this part of xtables?".

The main point for putting it in a stand-alone module is that it
is providing a network service. You could still use netfilter to
filter packets of course. I don't see where the big trouble is,
instead of using netfilter for receiving packets, you open up
a socket. That's basically it.

> I know xt_SYSRQ is used by quite a few people and it is seen as
> generally useful, so what needs to be done to get this into the mainline
> kernel?  Once it's there it stands a good chance of being backported to
> some of the production kernels (RHEL6, I'm looking at you) but without
> having some upstream commitment that seems a distant dream.
> 
> if xt_SYSRQ isn't acceptable, what is?  (Bearing in mind that I believe
> that whatever it is needs to be acceptable to a production environment.)

Lets see what other netfilter developers think, I'm easy to convince :)
One thing I'd like to see in any case however is review of the crypto
parts by the crypto people.

Re: Whither xt_SYSRQ?

[John Haxby]

On 11/05/10 18:06, Patrick McHardy wrote:
> John Haxby wrote:
>    
>> The standalone module is troublesome.  If I was starting from scratch
>> with that I'd be putting in filters and whatnot that match those
>> provides by xtables anyway.  If everything apart from the actual
>> function (sysrq) and password control is duplicated by xtables then
>> you'd have to ask "why isn't this part of xtables?".
>>      
> The main point for putting it in a stand-alone module is that it
> is providing a network service. You could still use netfilter to
> filter packets of course. I don't see where the big trouble is,
> instead of using netfilter for receiving packets, you open up
> a socket. That's basically it.
>
>    
>

/me slaps forehead

Sometimes the obvious just fails to make it through.  Yes, that makes a 
good deal of sense, I'll see how it pans out.  I'm currently wondering 
what happens when a machine is locked up whether or not I can get the 
service scheduled (one way or another) -- the netfilter stuff seems to 
be pretty robust in the face of machines locking up quite hard.


> Lets see what other netfilter developers think, I'm easy to convince:)
> One thing I'd like to see in any case however is review of the crypto
> parts by the crypto people.
>    

I'd like to see that as well.  I _think_ I've got the crypto stuff right 
but I do know that self-review for anything security related is 
basically worthless.  (As Bruce Schneier said, paraphrased slightly: any 
fool can produce a security solution that they can't crack.)

jch

Re: Whither xt_SYSRQ?

[Patrick McHardy]

John Haxby wrote:
> On 11/05/10 18:06, Patrick McHardy wrote:
>> John Haxby wrote:
>>   
>>> The standalone module is troublesome.  If I was starting from scratch
>>> with that I'd be putting in filters and whatnot that match those
>>> provides by xtables anyway.  If everything apart from the actual
>>> function (sysrq) and password control is duplicated by xtables then
>>> you'd have to ask "why isn't this part of xtables?".
>>>      
>> The main point for putting it in a stand-alone module is that it
>> is providing a network service. You could still use netfilter to
>> filter packets of course. I don't see where the big trouble is,
>> instead of using netfilter for receiving packets, you open up
>> a socket. That's basically it.
>>
>>   
> 
> /me slaps forehead
> 
> Sometimes the obvious just fails to make it through.  Yes, that makes a
> good deal of sense, I'll see how it pans out.  I'm currently wondering
> what happens when a machine is locked up whether or not I can get the
> service scheduled (one way or another) -- the netfilter stuff seems to
> be pretty robust in the face of machines locking up quite hard.

Netfilter receive processing runs in BH context. Its a bit of a hack,
but you could run your code in the same context by using a UDP socket
and marking it as encapsulation socket, see udp_queue_rcv_skb().

>> Lets see what other netfilter developers think, I'm easy to convince:)
>> One thing I'd like to see in any case however is review of the crypto
>> parts by the crypto people.
>>    
> 
> I'd like to see that as well.  I _think_ I've got the crypto stuff right
> but I do know that self-review for anything security related is
> basically worthless.  (As Bruce Schneier said, paraphrased slightly: any
> fool can produce a security solution that they can't crack.)

I'd suggest to copy the linux-crypto list on the next submission and
ask for review.