> > if you want to know what was changed, you use tripwire (well, everyone > > should do that anyway). that util shows changed, deleted, added, etc... > > the usual shit. of course, the database will have to be kept off of the > > box in question (since, again, tripwire could be re-run to cover up his > > tracks)... > If you keep the tripwire database off the box, tripwire can't use it to > check the binaries. The database should be created once, on a freshly (but > finished) install, and be burned on a cd-rom or rewritable (if > you use a RW, don't keep it in the writer ;) )
erm, heh. bad wording on my part. i meant "move a backup copy off of the box". > Even when you're running tripwire, it's quite simple to fool > things. Job de > Haas has made a kernel module for Solaris (kmod), that can hide processes, > and subsequently hide files for non-hidden processes. > It can also give filehandles to different files depending on if they're > opened or executed, or whatever system call tries to access them. > Tripwire will not see this. > I _know_ there is at least one linux kernel module that does all of this. great. even *more* i didn't think off at first. i've actually seen that patch (quite neat, but not what i would usually run... i'm not *that* paranoid, contrary to the paranoid tone of my previous letter). okay, let's see. we take the box offline, boot up with a clean kernel, copy tripwire + a known good database, run and compare. voila, that problem solved. > There is a lot of stuff that is not configfile or homedir, that > doesn't take > the blink of an eye to replace ;) i'm at a loss as to what this could be, but i'll take your word for it. > Isn't the md5 on a complete package enough ? If we worry that much about > integrity of files in a package, i think we'd better look at a different > problem; NMU's and non-trustworthy Debian programmers (or > upstream authors) it was really more of a random thought (not 100% serious). i mean, we *have* tripwire, and it works *great*... so why add md5sum to dpkg, indeed. i mean, we'd have to add exceptions to conf files, etc etc etc, and it'd all just be a kludge. > (don't worry - i'm not saying there are any, but we're talking > about healthy paranoia here) agreed. i trust (maybe foolishly, but still..) that any package in debian isn't designed as a rootkit in and of itself (altho, as the traceroute vulnerability has shown, it may be, unwillingly and unknowingly), and that it'll be found out and removed/fixed if it is. then again, i don't use that many weird packages lately, so i guess that is moot. > The moment somebody uploads a package of mine, with a suid binary that > executes a shell in it - who's to notice ? If the maintainer is not as > active as he/she should be, chances are that by the time the problem has > been fixed, _lots_ of boxes have security leaks. > I worry about stuff like that more than the checksums of > individual files in > packages. again, agreed. it was really more as a random "wouldn't-this-be-neat" feature idea than a serious "this-should-be-in-dpkg" feature idea. -m When you are having a bad day, and it seems like everybody is trying to piss you off, remember that it takes 42 muscles to produce a frown, but only 4 muscles to work the trigger of a good sniper rifle.
