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]

Message-ID: <4E011A96.7050509@redhat.com>
Date:	Tue, 21 Jun 2011 18:26:30 -0400
From:	Prarit Bhargava <prarit@...hat.com>
To:	Flavio Leitner <fbl@...hat.com>
CC:	netdev@...r.kernel.org, davem@...emloft.net, agospoda@...hat.com,
	nhorman@...hat.com, lwoodman@...hat.com
Subject: Re: [PATCH]: Add Network Sysrq Support

>> + * Note that the network sysrq automatically disables after the receipt of
>> + * *ANY* ping.  If you want to use this again, you must complete the
>> + * above four steps again.
>>     
>   

Hi Flavio,

> why not leave it running? perhaps disable it for some time to
> filter any ping retransmission, for instance netsysrq_reenable=10 seconds. 
> and then do if (time_after(jiffies, last_ping + netsysrq_reenable))...
>
>   

To be honest I have no objection to that, except that I thought the
community's objection would be about the security of this code -- I
specifically set out to make this as secure as I could (multiple
enabling steps, 30 digit hash, single-shot mode).

With your method someone *theoretically* could ping -p a system and
eventually crash it.  Of course anyone using this in production is crazy
and probably would end up getting what they deserved ;)

I'm certainly willing to consider your proposal -- but I have a feeling
that people would want this in single-shot mode over a rearming-mode.

> I have an USB KVM console, so often when testing workload, the USB takes
> ages to register the keyboard and I'd like to shot some sysrq+t or w,
> so if it disables after the first one, I can't get more traces because
> I simply can't enable it again.
>
>   

Yup.  One of the thoughts was to have the enable sysfs file take a
number from 1 to 5, which would become a countdown.  I thought it better
to get the base code in than muddy the waters with a potentially risky
(security-wise) proposal. (see later comment on ping flooding)

>   
>>     
>
> What about a whitelist of source MAC or IP addresses to accept the sysrq?
>   

Oh ... that's a great idea :).  I'll think about that for a later
enhancement if that's okay.  One of the other ideas that came up during
discussion was a maskfile of some sort that indicated what sysrq options
were available (maybe you *don't* want a sysrq-c to be executed).

> I'm thinking on a situation where we leave the systems with this enabled
> and then an ordinary user starts pinging the network guessing the hexa to
> cause reboots.
>
>   

Good point Flavio, but that's *exactly* why I wrote this in single-shot
mode.  I really think the code might be a bit too risky for most people
to deploy in production environments.  It's too risky for me to let
someone ping and ping and ping until they luckily hit the magic number
and figure out how to bring *all* of my systems down.  What are the
chances that a lab admin is smart enough to set the password to
different numbers across different machines in a single lab?

P.
--
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