Re: Secure 2.4.x kernel - readonly
On Mon, 24 Dec 2001, Anthony DeRobertis wrote:
> > making the disks readonly is not trivial ...
> > lots of work to make it readonly.. a fun project ...
> Not really. Nothing should write anywhere except /var and /tmp
> (did I miss any). Also, if you have users, then /home.
/etc is written into by the kernel ( for mounts/unmounts )
/proc if you use it is writable
vi /etc/foo.conf will sometimes create /etc/foo.conf.swp
and if you allow / ( /etc ) to be writtable... it defeats the
purpose of read-only / partition
- if you dont need to edit any files, not mount/unmount
than i dont think / needs to be writable
> In particular, if it is in $PATH, make it read-only. Many root
> kits trojan system binaries, and will fail on read-only media.
it fails for many reasons ... its fun to watch those the
deposit themself but cant get back up and running...so you can
see their rootkit and what they tried to do
> By using ramdisks, you can easily make the entire file-system
> read-only; you need only hit reset restore.
yes... but if an instruder got in ... you'd have to patch the hole
they used and rebuild a new ramdisk images
- but no different than a read-only hard disk
> >> o apt-get remove gcc
> > i'd remove make, tar and perl
> Won't removing tar break dpkg? And many other things? Same with perl?
> And without tar, how to do backups...
the classic argument .... security thru obscurity ..
( but dont use renaming by itself as your sole security measure...its not)
rename su to foosu
rename tar to footar
and change your code to use the new binaries
and it is good enough to trivially stop some of rootkits
and take a minute to prevent those attacks
- you know it worked .. when you find their rootkits
on your machine ...but they couldnt do anything
- at least its good entertainment..
when you are ready to do updates/upgrades... rename back to the orig names
and if your IDS is working... it should light up like a xmas tree
that binaries are appearing and disappearing