linux-kernel - Re: [RFC] Input: implement sysrq as an input handler

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: <20100401154212.GA7900@core.coreip.homeip.net>
Date:	Thu, 1 Apr 2010 08:42:12 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Linux Input <linux-input@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Jason Wessel <jason.wessel@...driver.com>
Subject: Re: [RFC] Input: implement sysrq as an input handler

Hi Pavel,

On Thu, Apr 01, 2010 at 03:34:55PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > root isn't really a problem from a security PoV (well, maybe it is if the
> > > operation isn't constrained by capabilities).  SAK can't protect you from
> > > root.
> > > 
> > > _Normal_ userspace behaviour running a root process is a problem if it
> > > blocks these handles, though, both for SAK and regular SysRQ.  I have lost
> > > count of how many times SysRQ+SUB delivered me from filesystem corruption
> > > and very annoying problems, both at home and at work.
> > > 
> > > We are sort of trusting userspace to not break the one way out from severly
> > > hung systems while doing its normal day-to-day operations (as opposed to
> > > deliberately disabling SysRQ or remapping SAK, etc).
> 
> If userspace disables sysrq during normal operation, that makes it
> useless.
> 
> If normal user could do that, that's a security problem.
> 

Yes, and...? This patch does not change the way one enables, disables,
intercepts, etc. SysRq and SAK compared to how it was handled when SysRq
was part of keyboard _input handler_. The only thisng this patch does is
moving the code into a _separate_ input handler.

> > > > That would require moving "these things", including their state
> > > > machines, into input core otherwise it would not know what events can be
> > > > trappable and which should be passed through. Or we should get rid of
> > > > EVIOCGRAB.
> > > 
> > > Maybe we can add a flags field to input devices and input handlers, to be
> > > able to have the core behave differently when needed, without moving
> > > everything into the input core?  Would that work, or would it need too much
> > > churn in the core?
> > 
> > The problem is that device does not know what SysRq and especially SAK are.
> > User can reassign key codes and key symbols easily.
> 
> That was not case in original implementation; it had hardcoded keymap.

The earth was also flat back then and the only keyboard was AT one. SAK
was always part of keymap so could be reassinged at any time.

> 
> > I don't think we had any issues like this since 2.5 so I would not worry
> > about userspace too much. If anything we just need to review what stuff
> > we run as root (we do that anyway, right?).
> 
> Hehe. If X can break sysrq, that's both X and sysrq problem.

Root can disable Sysrq... News at 11.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/