[Gllug] Hacker Attack
Nix
nix at esperi.org.uk
Wed Jan 11 12:25:40 UTC 2006
On Mon, 09 Jan 2006, Martin A. Brooks moaned:
> Nix wrote:
>> If they have root and /dev/mem is enabled or module loading is possible,
>> then you can't trust it.
>
> Servers shouldn't have modular kernels installed, imo.
My firewall UML instance has a modular kernel installed so that it can
load the digsig signed-executable-enforcement module.
It also has a triplet of patches applied:
- one which removes CAP_RAWIO from the capability bounding set
- one which deletes /proc/modules
- one which provides a new sysctl and /proc/sys file,
/proc/sys/kernel/module_seal; if you write 1 to this file,
module loading and unloading is forbidden; you can't write
0 to it.
So at boot, I simply need to do
/sbin/modprobe digsig_verif
echo 1 > /proc/sys/kernel/module_seal
and bingo, your kernel may be modular but you can't tell what
modules are loaded, or even that any are loaded, and you can't
load new ones or unload any.
I can't see an easy way to disrupt this kernel now, even as
root. /dev/mem, /dev/kmem and /dev/ioport routes are blocked by the
CAP_RAWIO removal: loading a module is banned (since of course I don't
bring the network up until some time after the kernel is sealed; if they
got root they could still remove the module_seal catting and reboot, but
that's about all they could do and it's rather obvious), and kernel
buffer overflows are blocked because the UML kernel is compiled with
SSP.
--
`I must caution that dipping fingers into molten lead
presents several serious dangers.' --- Jearl Walker
--
Gllug mailing list - Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug
More information about the GLLUG
mailing list