On Friday, December 21, 2001, at 03:25 , Gary MacDougall wrote:
Wouldn't it be nice to be able to run the kernel in "secure mode"?
I'm curious to know if we could limit the amount of "root exploits"
by this method, it would REALLY harden up security on a
Linux box... anyone have any opinions on that?
No, it wouldn't, at least from someone who is determined to hack
your box in particular (as opposed to a script kiddy who just
wants zombies). Script kiddies for the most part can be stopped
fairly easily by making their rootkit fail. Examples:
o Mount filesystems read-only.
o Make disks physically read-only [e.g., CD-ROM]
o apt-get remove gcc
and, most important:
o apt-get update && apt-get upgrade
Remember, exec'ing a shell is just convenient; no reason you
can't, for example, just make normal syscalls like
open/close/read/write to do your dirty work. I'm sure, given
enough time attacking, you could manage to malloc enough memory
to upload bash/csh/tcsh/ksh/etc. and then execute it without
even touching the exec syscall.
The problem you're trying to solve is to get the kernel to
refuse to execute exploit code. Exploit code looks just like any
other code to CPU. Good luck trying to get the kernel to tell
the difference.
In short: Would EPERM from exec stop a script kiddie? Probably.
Would it stop a dedicated attacker? No.
