Input: implement sysrq as an input handler
in [Kernel]
|
Prev: [PATCH 2/2] firewire: core: align driver match with modalias
Next: [Stable-review] [patch 070/123] ath9k: re-enable ps by default for new single chip families
From: Dmitry Torokhov on 22 Mar 2010 01:00 On Fri, Mar 19, 2010 at 11:53:29PM -0300, Henrique de Moraes Holschuh wrote: > On Fri, 19 Mar 2010, Dmitry Torokhov wrote: > > On Fri, Mar 19, 2010 at 01:06:41PM -0300, Henrique de Moraes Holschuh wrote: > > > On Thu, 18 Mar 2010, Dmitry Torokhov wrote: > > > > On Thu, Mar 18, 2010 at 09:00:43PM -0300, Henrique de Moraes Holschuh wrote: > > > > > Any chance of the user being able to avoid the SysRQ events getting to the > > > > > handle, e.g. by opening the input device in exclusive mode or something like > > > > > that? > > > > > > > > Yes, it is a possible to suppress SysRq by grabbing an input device. > > > > This possibility exisst with the current implementation too though - > > > > after all legacy keyboard driver implemented as an input handler as > > > > well. > > > > > > > > ... or am I answering a question different from the one you asked? ;) > > > > > > No, that's exactly what I wanted to know. > > > > > > What about SAK? That thing *has* to be untrappable. > > > > On what level untrapable? And what exactly is SAK? There is not a > > special key, at least not in general case, it is an action assigned to a > > key comboi. Root can "trap" legacy keyboard SAK with loadkeys; it can > > also disable sysrq, unload modules and do other nasty things. But > > ordinary users can not trap it. > > 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). > > > > Even for the SysRQ debug events, I'd feel better if we could have a class of > > > system input handlers that cannot be suppressed to use for these things. > > > > 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. > > > Given the fact that event devices are accessible only to root I think > > that current behavior is acceptable. > > I don't trust the class of programs that would want to open input devices as > root in exclusive mode. Desktop fluff might decide to use EVIOCGRAB or open > input devices in exclusive mode for some reason, and break SysRQ. I'd like > to preserve the hability of userspace to EVIOCGRAB if it feels there's a > need to, while preserving the kernel's hability to NEVER ignore SysRQ and > SAK while enabled. I am afraid that you chose wrong verb then. You can not _preserve_ what you do not have - legacy keyboard driver is still an input handler, and thus can still interfere with SysRq by grabbing input devices. 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?). -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pavel Machek on 1 Apr 2010 09:50 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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dmitry Torokhov on 1 Apr 2010 11:50 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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pavel Machek on 4 Apr 2010 09:30 Hi! > > 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. Yep, that was just a note. > > > 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. Well, there are two SAKs. One SAK -- in keymap, is remappable and always was. Second, sysrq-saK -- is (was?) hardcoded and not affected by keymap. Please don't change that. > > > 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. Root *does* disable sysrq is indeed news ... and 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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dmitry Torokhov on 16 Apr 2010 01:40
On Sun, Apr 04, 2010 at 03:27:34PM +0200, Pavel Machek wrote: > Hi! > > > > 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. > > Yep, that was just a note. > > > > > 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. > > Well, there are two SAKs. > > One SAK -- in keymap, is remappable and always was. > > Second, sysrq-saK -- is (was?) hardcoded and not affected by > keymap. Please don't change that. Can I change Alt? Just saying... ;) Anyway, yes, it was hardcodced in 2.4. It also was only working on AT keyboards, and now we support much wider range. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |