Why Sysrq+k does not offer a trusted path

Why Sysrq+k does not offer a trusted path

[Oliver Tennert]

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

Re: Why Sysrq+k does not offer a trusted path

[Bernd Eckenfels]

In article <Pine.LNX.4.44.0309290836460.16991-100000@picard.science-computing.de> you wrote:
> Thus it is a more secure way to offer a real SAK.

Well, root can still disabled it, for example by debugging kernel memory.
Generally, unless you ise priveledges, you cant avoid having root disable
SAK. But this is not the real problem anyway. SAK is supposed to protect
users from other non priveledged users. The main problem with SAK are
various graphical console modes, which cant be easyly restored. I think
currently SAK is not interpreted in all keyboard modes, do avoid somebody to
kill off the console in a inconsitent state. There are for example some
X-Servers which need to reset the text mode by themself or the display is
lost.


Greetings
Bernd
-- 
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/

Re: Why Sysrq+k does not offer a trusted path

[viro]

On Mon, Sep 29, 2003 at 08:53:59AM +0200, Oliver Tennert wrote:
> Thus it is a more secure way to offer a real SAK.
> 
> Or am I missing a very important point?

Scanning through the file descriptor tables of processes does not catch
every opened file out there.  For trivial example consider attaching an
open file to SCM_RIGHTS datagram and sending it to yourself.  Then close
the original descriptor.   Later you will be able to receive the datagram
and get your opened file back.