Re: [PATCH]: Secure SysRQ for 2.1.108.
Myrdraal (myrdraal@jackalz.dyn.ml.org)
Sat, 11 Jul 1998 08:22:48 -0400
On Sat, Jul 11, 1998 at 10:13:10AM +0200, Riccardo Facchetti wrote:
Hi,
> On Thu, 9 Jul 1998, Myrdraal wrote:
> > 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!).
I'm happy to hear thoughts on this subject.
>
> 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 ?
It is, but the file is readable only by root. (600 permissions). If someone
has root they can do *more* nasty things than using SysRQ if they feel like it.
>
> [...]
> > +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.
Actually, most of my use of SysRQ has been recovering from crashed
graphics programs, or when the system has crashed, but is still
somewhat alive. That's just me, though. Well, yes. Okay, you said
authenticating that way could be too slow; what's your idea to fix
that problem? :) Also, in alot of situations, console access=access
to do whatever you want (if you know what you are doing), so I think
that people who password protect SysRQ will most likely be in the
minority. One other thing; would making it so you don't have to
hold the SysRQ sequence while you type the password cure that?
> [...]
> > +/* 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).
They could do that, however they would have to be root.
-r-------- 1 root root 67112960 Jul 11 08:14 /proc/kcore
As you see, only root can read from this file.
> > +/* 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 ?
I doubt it. They would have to be root.
> [...]
> > +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 ?
When you say keeps pressing the SysRQ key, you mean keeps typing in many
letters for the password? I don't see how this could possibly use up much
CPU as you would have to type *extremely* fast, and also once you hit
more characters than the actual password has, it just ignores then basically.
Once you type a wrong or 'overflowing' character sysrq_blewit gets set.
-Myrdraal
--
Linux jackalz 2.1.108 #103 Thu Jul 2 03:18:16 EDT 1998 i486
8:15am up 9 days, 4:58, 20 users, load average: 0.00, 0.00, 0.00
-
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