Messages in this thread | | | Date | Mon, 29 Sep 2003 08:53:59 +0200 (CEST) | From | Oliver Tennert <> | Subject | Why Sysrq+k does not offer a trusted path |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |