![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2005-03-22 13:48 [from the cache] ©2003-2008 | |||||||||||||