Why Sysrq+k does not offer a trusted path

[Oliver Tennert <tennert@science-computing.de>]

Hello,

the Sysrq documentation states that the sequence Sysrq + k is not supposed
to constitute a SAK as specified for a C2 system.

Although I do not quite know what excatly in the author's view is missing
for Sysrq + k to really offer a C2 compliant trusted path for logging in,
at least I know of one thing which in a trivial way constitutes a security
leak:

As "/proc/sys/kernel/sysrq" is writable for any privileged process,
writing a "0" into it leads to switching off sys requests altogether. A
malicious program can then do just that and otherwise simulate the
functionality of sys requests its own way. Forging a secure login path is
then a trivial task.

My question is: why not eliminate "/proc/sys/kernel/sysrq" altogether, and
decide at boot time if sysrq functionality is wished or not?

Setting the variable sysrq_enabled at a very early stage of the kernel
setup based on a command line parameter "sysrq" would be a very convenient
way to decide if sys requests are to be enabled, and moreover this
procedure cannot be overridden once the kernel has booted.

Thus it is a more secure way to offer a real SAK.

Or am I missing a very important point?

Best regards

Oliver Tennert

--
________________________________________creating IT solutions

Dr. Oliver Tennert			science + computing ag
phone   +49(0)7071 9457-598		Hagellocher Weg 71-75
fax     +49(0)7071 9457-411		D-72070 Tuebingen, Germany
O.Tennert@science-computing.de		www.science-computing.de