Re: Root Kit Protection
On Wed, Feb 16, 2000 at 08:16:05PM -0900, Ethan Benson wrote:
> On Wed, Feb 16, 2000 at 09:55:21PM -0500, Mike Markley wrote:
> > I've decided to go ahead and write someting like this in perl for my own
> > ease-of-use; it'll be GPL. The administration details are the interesting
> > part... I'd like to use the MD5 sums from /var/lib/dpkg/info/*.md5sums but
> > I'm really not sure how to ensure that these haven't been tampered with since
> > installation. Perhaps if we could integrate it with tools such as
> > dpg/apt/etc to add the necessary MD5sums to a configuration file and PGP
> > sign said file... however, PGP signing a file automatically would be very
> > difficult to automate. All of this is coming off the top of my head so I may
> > be missing a very obvious way to handle this; any input? It'd be much
> > appreciated...
>
> the md5sum database MUST be either 1) on immutable media (write
> protected floppy, or CDROM) or 2) cryptographically signed with
> GPG/PGP. the former is impossible to automate really since it
> requires the user to make hardware modifications to save the
> immutable database.
>
> cryptographic signatures however i see being done one of three ways:
>
> 1) debian distributes a complete md5sum database of every single file
> in the distribution signed by a single debian GnuPG key. this would
> have to be redownloaded at every update (with apt-get update say) and
> i would guess it would be HUGE.
>
> 2) each package has a md5sum list of every file it contains, this list
> is signed by the maintainers GnuPG key. when a package is installed
> this signed list is added to the system list. I think this might be
> rather slow as a verifcation has to perform many separate signature
> verifications (1000 packages installed 1000 GnuPG signutures to check
> for each package list)
>
> 3) md5sums of all files are gathered together in a single database
> (either by gathering the md5sums from the packages, or less preferably
> scanning the disk) and that database is re signed every time its
> updated by the administrator's private GnuPG key.
>
> i think that 3 is really the only practical way to go. everything can
> be automated up to asking for the admins GnuPG passphrase, and we
> don't end up with yet another huge database/index to download.
I agree with this.
> somewhat related to this, i think that 3 improvments to the packaging
> system would be benificial:
>
> 1: packages include GnuPG signatures to ensure they are genuine
> (protect against mirror tampering etc.)
Definitely.
> 2: packages include a complete md5sum list of all files in the
> package.
Doesn't the DEBIAN/md5sums file already do that?
> 3: dpkg on package installation adds the package's md5sum list to the
> system database, and (if configured to do so) asks for the GPG
> passphrase to sign the database.
Agreed as well.
> some other niceties this system could have:
>
> a utility to scan and update a separate list of md5sums for
> configuration files, configuration files are easy to find given they
> are marked in the deb packages, since the admin likely alters
> configuration files the debian md5sums will be rendered invalid, a way
> for the admin to maintain a local md5sum database of the configuration
> files will allow him to be alerted if something is altered without his
> knowledge. (he would of course need to rerun this utility after every
> config alteration)
>
> a utility to take care of locally installed software in /usr/local
> basically a tripwire that is Free software, but included as part of
> the dpkg tripwire so that reports and scans are unified, avoiding the
> need to maintain 2 separate and unrelated implementations of the same
> thing.
>
> I really think for this to be usefull it needs some hooks into the
> packaging system, without those hooks you just end up with a tripwire
> clone with all of its inconvenences intact.. (there may already be
> such a clone its been awhile since i checked.)
Absolutely. At the moment I am writing a very stripped-down thing (although
I overcelebrated my birthday and the resulting "effects" put off work on it
till tomorrow), but I plan to make it easily modifiable for such things as
this. Unfortunately, the only machine of mine that's not a "production"
server is on an incredibly slow link, so I have little idea of what's
happening as far as perl hooks into dpkg/apt and configurability of apt/dpkg
to include outside commands when doing stuff; I do remember something about
setting up apt to remount /usr read-write while instaling and to remount it
ro again when finished. If dpkg is able to do something to this effect, it
should greatly simplify the whole thing. And if none of this made sense,
please feel free to email me tomorrow once I'm recovered from the
celebration :).
--
Mike Markley <mike@markley.org>
PGP: 0xA9592D4D 62 A7 11 E2 23 AD 4F 57 27 05 1A 76 56 92 D5 F6
GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084
Oblivion together does not frighten me, beloved.
- Thalassa (in Anne Mulhall's body), "Return to Tomorrow", stardate 4770.3.
Reply to: