[1647] in linux-security and linux-alert archive
[linux-security] Re: Re: Malicious Linux modules
daemon@ATHENA.MIT.EDU (Andrea Mennucci)
Mon Oct 13 04:16:15 1997
From: mennucci@cibs.sns.it (Andrea Mennucci)
To: linux-security@redhat.com
Date: Sun, 12 Oct 1997 19:47:00 +0100 (DFT)
In-Reply-To: <199710091516.KAA19281@dancer.1stnet.com> from "Runar Jensen" at Oct 9, 97 10:16:32 am
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
hwllo
>
> In message <199710091142.HAA29040@mail.clark.net>, "Peter W" writes:
>
> >> The implications should be obvious. Once a compromise has taken place,
>
> > Either of these situations would be "caught" by a properly configured
> > Tripwire.
>
> Once root access is gained, the module could very well be compiled and placed
> anywhere on the drive (like a home directory), loaded, and _then_ moved to
> /lib/modules.
What about this (for very secure sites and/or paranoid)
1) a (patched and minimal) kernel on a diskette,
with (patched and minimal) tripwire on it and the database.
At boot time tripwire is executed (instead of init) and it
fsck the disks, then it checksums (this may be done by contructing the
databases, not related to the all-mounted-filesystem, but to the single
partitions) ; if the checksum is ok, the diskette is unmounted and
the ususal root partition is mounted as / (I do not beleive this can be
done right now) and tripwire execs init; otherwise
the console is queried for directions on what to do.
If an intrusion is probable, rebooting is a safe way to know what has
happened
2) A family of patches or modules for kernel, I would call ``guardian''
guardian.modchksum
this module is loaded with a chksum of current trusted modules
When someone (even kerneld) asks to load a module, the module is
chksummed and refused if it is not recognized
guardian.nowrite
this module prohibits writing to a device.
It can be used to protect /dev/hda (so that the MBR cannot be altered)
or even the partition where /bin /etc are (in this case,
maybee a ramdisk is created and mounted on tmp as first thing at boot time,
and files like /etc/ldso.cache and /etc/mtab are linked in tmp; or
I would suggest to write a module for the kernel called ``ramfile''
that is used to have certain files reside in ram)
(The swap device needs probably to be protected somehow ?)
When a system is properlly installed, even /usr could be locked.
guardian.notrm
this module prohibits that any module called guardian* be unloaded
(why not introduce a kernel password, that is asked when
you rmmod a guardian module?)
I believe this solution 2 is probably the best: you can have a fast
system, you install it, then you lock it tightly, and it
is as secure as the kernel is (and not as the weakest program you install)
I am not good enough to build this modules, less even to be sure they cannot
be bypassed
A.Mennucci
--
----------------------------------------------------------------------
Please refere to the information about this list as well as general
information about Linux security at http://www.aoy.com/Linux/Security.
----------------------------------------------------------------------
To unsubscribe: mail -s unsubscribe test-list-request@redhat.com < /dev/null
