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] [day] [month] [year] [list]

Message-ID: <4E04A11A.7000104@oracle.com>
Date:	Fri, 24 Jun 2011 15:37:14 +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:
> 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.

Having just read the entire thread I have some different comments.

I think I mentioned that the standalone module didn't fly because I was
using an encapsulation socket: this preserved the ability to protect the
sysrq with iptables and also kept things nice and simple.  Unfortunately
that also meant I lost IPv6 ....

One of the comments in the thread (sorry, I've lost the attribution, not
to mention the exact quote) was that you would be crazy to run this in
production.    Hmmm.   One of the principle use cases of this is
precisely to run the code in production: machines in production do go
AWOL for all kinds of reasons and being able to run sysrq-m, t, s and c
is particularly useful.   It would be nice to be able to go up to the
machine and type on its keyboard.  If only it was even on the same
continent.   If only it a keyboard.  Or even a PS/2 keyboard socket
(getting a USB keyboard to configure itself when the machine is wedged
is, well, unlikely).

The changes I made to the xt_SYSRQ hashing a while back to avoid things
like replay were precisely because it needs to be run in a production
environment.   I've just submitted a patch that makes replay to other
machines that have the same password less likely to succeed, again, with
a view to how this thing would be used in production.

Sorry if I've repeated some things that have already been said.

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