[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Secure 2.4.x kernel



hi ya 


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
http://www.debian.org/doc/manuals/securing-debian-howto/


have fun hardening
alvin
http://www.Linux-Sec.net


> 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.
> 



Reply to: