sysrq is now completely disabled, it would be nice to maintain the ability to reboot etc

This bug was fixed in the package procps - 1:3.3.3-2ubuntu3

---------------
procps (1:3.3.3-2ubuntu3) quantal; urgency=low

  * debian/sysctl.d/10-magic-sysrq.conf: adjust to 176 by default, retaining
    support for the critical sync, remount, reboot functions. SysRq+E and
    SysRq+I are still disabled, which unfortunately means SysRq by default
    cannot be used to kill a broken X server; but the only way to enable
    these would be to re-enable SysRq+F, which is one of the options that's
    problematic security-wise. LP: #1025467
 -- Steve Langasek <email address hidden> Mon, 16 Jul 2012 17:06:59 -0700

is it possible to enable SysRq+K?

Yes, check out the file /etc/sysctl.conf or /etc/sysctl.d/*magic*.conf. There you will see to what point sysrq is enabled and you may change what to enable in future occasions. To set the enabled features instantaneously you might as well just read the files I listed for documentation, and save the number of your convenience to /proc/sys/kernel/sysrq.

This affects raring

Booting Ubuntu Desktop amd64 liveDVD (3.8.0-19-generic) in BIOS mode searching "computer" using file manager to find sysreq settings is now found in /etc/systl.d and named 10-magic-sysrq.conf. Looking in my Ubuntu partitionb which was last bootable using 3.8.0.28 kernel; also confirms sysrq as being disabled by default Can not find why this has been disabled as default so would like to take opportunity to ask; Why is sysrq disabled as default on liveDVD?

Reading the original bug report refers to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/194676 confirms there may be secuity issues related to this. Is it possible to ask for some reasoning to this? I thought linux had reputation of being secure and virus free!?

Is not a better idea to have sysrq enabled to allow the well known and used RSEIUB(O) if sytem hangs or freezes? At least providing the protection of minimising having to recover sytem files or data due to corrupting hard drive and the need for fsck to kick in or be started manually from recovery.?

Am asking these questions after watching 17 08 2013 episode of the BBC programme ["Click"](http://www.bbc.co.uk/iplayer/episode/b0392vqy/Click_17_08_2013/) and the "cyberwarfare" article really caught my attention. FAWC

If sysrq is disabled by default and users are saying it works for them (Ask Ubuntu) ie http://askubuntu.com/questions/53263/shut-down-computer-from-keyboard/53266#53266 Perhaps this is evidence of why full disablement of sysrq is applied by default? ie If user did not set sysrq on; Who did?

Sorry wrong link- intended to post http://askubuntu.com/questions/11002/alt-sysrq-reisub-doesnt-reboot-my-laptop

Apologies once again. Now understand S U B are only sysrq commands allowed by default by the use of bitmask 176 which for it is easy to change or adapt relevant settings to any other commands as needed or desired. This for me is applicable to 12.10 and 13.04 desktop amd64. Suprisingly very little information regarding sysrq in Official Ubuntu Documentation. Have posted an answer with much useful information regarding the use and configuration of sysrq in the link posted in last comment. The majority of the answer is copied from another ditrubitions wiki which is based on the Linux Kernel Documentation regarding sysrq. The conclusion to the answer in linked Ask Ubuntu question above is to leave the default settings as is unless there is obvious need to do otherwise. Just use SUB instead of RSEIUB! Tryng sysrq commands in tty will give text output which helps understand and prove there never was a complete disabling of sysrq. Have taken back my affected vote as a little research has proven i am unaffected. Another example of how Ask Ubuntu is a brilliant learning tool and just one of the many brilliant resources available through using Ubuntu! Links provided by mniess in other answer to the same question are key in understanding and appreciating why the need for different bitmask has come about and this is not a new concept.