Re: [RFC] Input: implement sysrq as an input handler
From: Dmitry Torokhov
Date: Thu Apr 01 2010 - 11:42:33 EST
On Thu, Apr 01, 2010 at 03:34:55PM +0200, Pavel Machek wrote:
> > > 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
> 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/