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-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
