Re: snooper watchers

[mouse () Collatz McRCIM McGill EDU (der Mouse)]

There's been quite the discussion about protecting your machine, stuff
like

> > > > Are you going to write a program that checks to see if root's
> > > > cronjob has been modified?
> > > I suppose if you really wanted to make sure that crontab entries
> > > couldn't be changed is to put them on a write protected floppy,
> > > mounted at boot.
> > The best thing to do is to run tripwire from a read-only device
> > (like a floppy)
> What is to stop someone from mounting another filesystem over the top
> of your tripwire database and crontab entries.  Replace the mount and
> df commands to not show the new mount point.

> You really need to do a seperation of the checkee from the checkor.
> If someone has root access on the machine, the could basicly do
> anything that is needed to cover their tracks.

If I might offer a suggestion:

- Your "system" stuff is on a pack with physical write-protect (many,
  perhaps most, disks have a write-protect jumper; it's just a question
  of bringing it out to a switch on the housing).  This includes boot
  device and all "system" filesystems (/, /usr, etc).

- All remaining (read/write) filesystems are mounted noexec, and your
  logfiles are set append-only.

- When you want to update an executable, you (a) power off the machine,
  (b) disconnect its netlink, (c) flip the write-protect switch, (d)
  boot, (e) do your changes, (f) power off, (g) flip the write-protect
  switch back, (h) reconnect the net, and (i) come back up.

I'm going to (once I have the disk to do so) set up a strongbox machine
using just such a scheme.  With the hard write-protect, you know that
even if an attacker somehow gets a fully-powered root shell, your basic
system _can't_ be destroyed or trojaned, and that includes the mount
table (since it's on your boot pack).  All the attacker can possibly
damage is the logfiles on the writable pack, and even that would
require breaking the kernel to the extent of being able to sidestep the
append-only bit.  (I'm assuming, of course, a system that _has_
append-only files, and won't let the append-only bit be cleared unless
you're in single-user mode, something like what NetBSD does.)  The
noexec mount points for the read/write pack are to make it harder to
trip over trojans left lying around there.

Obviously, as I have outlined it, this is not acceptable for a machine
with users on it, if only because users normally expect to be able to
run their own executables.  If you drop the noexec part, it might be
workable for a machine with users; the physically read-only system pack
still makes it highly resistant to trojaned versions of things like ps,
ls, du, or even the kernel.

Of course, you need the discipline to never write-enable it without
bringing the machine down first and disconnecting it from the net, but
if you can't handle that you have a human problem much more serious
than any technical problem. :)

You also need a system that can run with read-only "system"
filesystems.  Some systems make this easier than others.  I've done it
with NetBSD (with root on nfs rather than local disk); I suspect most
systems can tolerate it with a little creative symlinking if necessary.

                                        der Mouse

                            mouse () collatz mcrcim mcgill edu