Re: Secure 2.4.x kernel
On Mon, 24 Dec 2001, Anthony DeRobertis wrote:
> 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?
lots of varying opinion...
> 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]
making the disks readonly is not trivial ...
lots of work to make it readonly.. a fun project ...
> o apt-get remove gcc
i'd remove make, tar and perl
its fun to see installed new root kits that couldn't finish its
tasks cause gcc and tar etc is missing...
- never did understand why the rootkit didnt come with
its own pre-compiled binaries ...
> and, most important:
> o apt-get update && apt-get upgrade
that assumes that security.debian.org is listed in sources.list
( *sorry* just had to add the comment.. :-)
lots of stuff to do to harden your debian box
for simplicity... one can start here
have fun hardening
> 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.