Rootkit

[Andrew Kelly]

On Tue, 2007-10-23 at 09:19 +0300, bob.smith at kolumbus.fi wrote:
> Dave Burns <tburns at hawaii.edu> kirjoitti: 
> > > >> While reading this thread it occurred to me that if disk drives had a
> > > >> read-only switch, then systems would be uncrackable.
> > 
> > Well, that would go a long way to make intrusion more difficult, but
> > not impossible. Intruder just mounts something on top of your read
> > only partition that looks a lot like your partition but with a few
> > well chosen modifications. He then has to hide evidence of his trick,
> > which would not be easy (at least for me!), but that's not to say it
> > could not be done. In fact I have heard of a very similar approach
> > being used (sort of the opposite - an innocuous partition mounted over
> > a partition full of rootkit stuff to keep it hidden), though
> > apparently the intruder had not perfected it yet, since the admin
> > eventually figured out what was going on.
> > 
> > > There are special filesystems ("unionfs" ?)
> > > that redirect writes to a read-only file to a copy of the file in a
> > > writable partition (I think).
> > 
> > Yeah, but wouldn't that defeat the idea? Are you making it read only
> > so that you know for sure it is good and can use it with confidence or
> > so that you can easily recover your original files after getting
> > (expletive deleted)? This "read-only" partition approach is only worth
> > the trouble if it actually takes some capability away from the
> > intruder. If the filesystem is read/write but your "originals" are
> > read only, that only bothers the intruder if he actually wants to
> > erase them. What does he want to erase? Log files, which do not belong
> > on a read only filesystem in any case.
> > 
> > You could use it for monitoring - if it was easy to do a check whether
> > ps and lsof and other critical executables were actually on the
> > read-only part of disk or had been modified. The utility that does the
> > check had better be on the read only partition, but what do you use to
> > check it? If you're totally hacked you can't be sure that the
> > utilities that you execute are actually coming from that disk.  You
> > might be logged in to an emulator! Might as well use tripwire or aide
> > and not bother with the read-onlyness.
> > 
> > This has got me thinking.
> > Dave
> > 
> > -- 
> > fedora-list mailing list
> > fedora-list at redhat.com
> > To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
> > 
> 
> Hi, I am glad you are discussing this, because there are issues to ponder. 
> 
> About hacking and cracking. A while back I had this idea, well a few years back, but it was put aside because a university professor disregarded it as useless. and maybe it is. 
> 
> The idea was to create sort of(in some way) "encrypted and protected" executables. This to be able to verify that an executable is what it is(located on machine X, and compiled on machine x). Further, the executable would be made so that it could not run on a system on which it was not allowed to run. That was the basis of the idea. Purely theoretical. How this could be achieved in reality is beyond my current knowledgebase, but I am sure that someone else with more knowledge in encryption and protection than me, could maybe analyse this further. 
> 
> (Sure, most machines are loaded with translators and script interpreters like perl, and PHP and many others, which allows for making quite much damage through scripting. )
> 
> Still, it could be something to think about. 
> 
> best r
> Bobo

Silly thought: what about using a public/private key setup, to encrypt
the names of all executable files?

Andy