On Thu, Dec 21, 2000 at 02:33:32PM +0100, Christian Kurz wrote: > > 1. Reboot with a clean kernel > > 2. Run tripwire with my read-only record > > 3. Install my Debian packages > > 4. Update my read-only record > > And you are running the system with an unclean kernel? If you not add > your kernel that you are running to the tripwire check, you won't notice > if anyone puts a bad module or a modified kernel on your system. Sorry, I wasn't clear enough. "Reboot with a clean kernel" should be "boot a clean system" - ie, a boot floppy or CD-ROM with a kernel *and* a filesystem. > > > My suggested alternative is a system which knows about official Debian > > packages, and will register that change as simply "installed/upgraded > > package XYZ". > > Where should it register that? What exactly should it register? Your > current description sounds like a system that just notes that package > foo has been instaleld and nothing else. This will still make it > possible to replace foo with an modified foo that allows someone to take > your machine over. If you are willing to trust your Debian mirror (or perhaps you could even circumvent the mirror and go to .debian.org for signed checksums), the audit tool will tell you "replaced foo with upgraded (official) foo version#", or "ALERT: foo does not match official checksums". You could produce output like this with a read-only archive or a security server, or you could just print a list of installed official packages. Not perfect, but much easier than using tripwire *and* no less secure (since you always have to trust your source of .debs). > > Hence my comment. "Less-clueful" intruders won't modify > > /var/lib/dpkg/info/package.md5sums ; debsums will catch these people, > > but will not help if the cracker is smart. > > No, as it would say that if this md5sums will be wide spread, someone > will write a tool to modify binaries without modifying the md5sum and > then you have the problem again or even create a tool that replaces the > md5sum in the file /var/lib/dpkg/info/package.md5sum with a new one, so > that debsum won't notice the difference. I think we're agreeing with each other. I said "debsums is inadequate", you appear to be trying to explain this to me. > > Of course, at some point, you have to make a leap of faith. ATM, most > > Debian users trust their DNS server and their Debian mirror. IIRC, > > Connectiva's modifications to apt-get will fix the "trust your DNS" > > problem. > > Well, but you still have to trust your mirror and their admins? So how > do you want to make sure that you can trust this mirror? Which > modifications of apt are you talking about? What exactly did they > modify? Did they change apt to not accept hostnames but only ip-address? http://freshmeat.net/news/2000/12/02/975819599.html Search for "mirror authentication". I'm not sure how they did it, but if I were trying to do mirror authentication, I'd ship apt with an official .debian.org public key, and then ask .debian.org whether a the public key presented by a mirror was kosher. There are other ways of doing it... This is better than using IP addresses, because someone could maliciously re-route your traffic. Also, it might tip you off that someone was poisoning your DNS server... > > > A kernel source is "clean" when it has the Debian kernel maintainer's > > signature on it. A kernel binary is clean when the administrator: > > Which signature? If you download a debian package there's no signature > on it that you could check. So how do you want to check a signature and > make sure that there's no poisoned kernel-source on your debian mirror? > > > * gets a clean kernel source > > * compiles it, and records the md5sum of the kernel with the "security > > server" (or on a piece of paper). > > Of the kernel? What do you mean with kernel? Only vmlinuz? Or also the > modules? Be more precise. Okay, perhaps I was again insufficiently precise. The kernel needs to be treated specially, because it is frequently compiled from source (and is also obviously very security-sensitive). The modules are conceptually part of the kernel. Under my proposed scheme, you still need to treat the kernel in the same way that you treat everything with tripwire. > What do you define as "vanilla"? Also remeber that rootkits can change > and become more sophisticated in the future. And so you will also be in > a time lag behind the people having the rootkits as you first have to > get a copy of it to create a detection for it. > > > As new rootkits are observed "in the wild" (and a tool like this might > > help find them :), they can be added to the list of trojan signatures. > > This is closely analogous to the operation of virus scanners in M$ land. > > So you really think that someone who will write such a tool will be able > to get acccess to all rootkits? I hope this is not meant serious. > I'm not claiming to have a solution for automatic rootkit detection. As I said in the original email, kernel (and module) scanning is just an extra feature which is not perfect, but which might help somebody one day. Of course, there will always be new or mutating rootkits (like there are new or mutating virii on Windows), but if any rootkit is in widespread use, it will be detectable. You seem to have substantially misunderstood what I've been saying, so I'll try summarising my proposed design goals to see if this at least makes some sense: * tripwire-like functionality, which enables the admin to know that a machine is the same as it was when they snapshotted it * automatic recognition of changes to the snapshot which correspond to the installation of packages from /etc/apt/sources.list, possibly augmented by mirror authentication * the ability to create a safe snapshot "in retrospect". This involves manually auditing all the files that do not match official debian packages. Obviously, if you've installed binaries, you may only be able to "audit" them by re-installing them.... * (optional) some additional tools for auditing parts of a system which tripwire users are normally forced to ignore -- |> |= -+- |= |> | |- | |- |\ Peter Eckersley (pde@cs.mu.oz.au) http://www.cs.mu.oz.au/~pde for techno-leftie inspiration, take a look at http://www.computerbank.org.au/
Attachment:
pgpg5RJ2ae8tx.pgp
Description: PGP signature