> This is the (I believe) finished version of my secure SysRQ patch. It
> allows you to password protect SysRQ commands or toggle SysRQ entirely.
> Is there any chance of this making it into 2.1.x?
I want to comment on some things I have noted reading the patch. May be I
am wrong, but I would like to let you know what I think.
They are just thoughts: note that SysRQ IMHO is a VeryGoodThing(tm) and
saved my ass more than one time (much more!).
Now imagine Sue-sysadm enabled SysRQ in her brand new installation of
2.2.0-based account server. She have hundreds of accounts to manage and
not all her users are nice and collaborative.
[...]
> + /proc/sys/debug/sysrq_password:
> + This file contains the current SysRQ password. This file is only readable
> + by the superuser. Example of setting the password:
> + echo "mypassword" >/proc/sys/debug/sysrq_password
> + Note that if sysrq_secure is set to "1" and the password is not set, you
> + will not be able to authenticate.
Is mypassword in clear text ?
[...]
> +Authenticating when in secure mode;
> + 1. Press SysRQ-n.
> + 2. Hold the SysRQ combination as you type your password.
> + 3. Press SysRQ-ENTER.
> + 4. Perform your SysRQ command. Authentication will be reset.
But how about when you are in hurry ?
Imagine a situation that fits most of SysRQ usage. A machine has becoming
instable: filesystem started to slowly corrupt or you have a process that is
doing stupid things or kernel is becoming crazy and wants to toast your hard
disk or there is an attacker on the machine and you want to freeze the machine
whithin microseconds to freeze the log files: SysRQ-u (remount read-only so
that noone can write to the disk) and then SysRQ-b if you have the suspect
that kernel is still trying to toast your disk.
A 2.2.0 sysadm that enable SysRQ and then want to stop Joe-user from
remount R/O or boot the machine will password-protect that keys but then
IMHO SysRQ become a false and dangerous tool to count on in critical
situations.
[...]
> +/* List of sysrq keys that you need to authenticate to use. */
> +char sysctl_sysrq_secure[64] = "";
This is the vector containing the password. The password is in clear text.
If Evil-user do 'strings /proc/kcore' will be able to read the password
(okay, must find it, but I don't count on difficult in finding the
password in memory: usually Evil-user is smart enought to find it).
> +/* The password we require to use sysrq if sysrq_secure is set. */
> +char sysctl_sysrq_password[64] = "";
Then again this vector contain the password as it is typed in by sysadm. Isn't
this something that may help Evil-user to find out what the password is ?
[...]
> +void read_password_char(int key) {
What if an user keeps pressing a SysRQ key ?
I have not tried it but I imagine the SysRQ kernel code to autenticate the
SysRQ sequences will be executed in loop "stealing" CPU and some I/O from
user processes. Isn't this something that can be regarded as denial of
service ?
Ciao,
Riccardo.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html