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]

Date:	Thu, 1 Apr 2010 15:34:55 +0200
From:	Pavel Machek <pavel@....cz>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
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!

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

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

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

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/