On Mon, Dec 20, 2010 at 8:53 PM, Craig Ringer <craig@xxxxxxxxxxxxxxxxxxxxx> wrote: > > Do you have a trusted boot path from BIOS to bootloader to kernel to init > core userspace, where everything is digitally signed (by you or someone > else) and verified before execution? Do you disable kernel module loading? > > If not, you're wasting your time, because a compromise by malicious kernel > module, modified init, modified md5 command, etc will render your > precautions totally pointless. > > If your BIOS can't verify the bootloader, which is likely on an x86 / x64 > system, then you can still get some protection by signing your kernels and > using a bootloader that checks signatures. If someone messes with the > bootloader you lose, but it'll help protect you against obvious automated > attacks. You might be able to use the Trusted Platform Module (TPM) on your > machine to get a fully verified chain of trust, though, by using Trusted > GRUB. > > http://trousers.sourceforge.net/grub.html > > If you can reasonably trust that the kernel you loaded is OK, you can have > it verify signatures on binaries before executing them. There was a DigSig > project for that (http://disec.sourceforge.net/) but it seems to have > stopped recently. I'm not sure if there's any replacement. > > Without kernel-level signature verification, all you can really do is have a > custom initrd/initramfs (signed and verified by grub during boot) that > checks the signatures on init, md5, gpg, libc, etc etc (any binary root > runs, including scripts) before switching to the real root FS during boot. > Then you can have your Pg startup scripts (which you signed on a separate, > trusted machine) verify GnuPG signatures of the Pg binaries before > execution. > > All in all, it's a painful, clumsy way to do things, and AFAIK there's > little support in mainline Linux systems for trusted boot and trusted-binary > systems. You might find out more with a search for "linux trusted > computing", "linux trusted boot", "linux tpm", "linux signed binaries", etc. > > Personally, I'd be using existing system- and network-level intrusion > detection tools like tripwire and snort to try to spot intrusion if and when > it happens. I'm not confident that a chain-of-trust approach is workable on > Linux systems at present, though I'd love to be proved wrong by being > pointed at existing support I've missed. > > -- > Craig Ringer > I find it very comforting that I am not the only one who finds this requirement a bit "out there". Unfortunately, these requirements are set in stone, and no matter how hard I try, can not be altered. We live in a world where compliance is king. Nevermind if compliance doesn't actually make the system more secure. Unfortunately Tripwire does not meet the full requirement, as it does not prevent the database from starting. Ken -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
