On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote: > On Sep 06, 2007, at 11:06:16, J. Bruce Fields wrote: > > On Thu, Sep 06, 2007 at 01:44:05PM +0530, Satyam Sharma wrote: > >> Like Trond said, there are very high number of ways in which > >> privileged userspace can compromise a running kernel if it really > >> wants to do that, root-is-God has always been *the* major problem > >> with Unix :-) > >> > >> The only _real_ way a kernel can lock itself completely against > >> malicious userspace involves trusted tamperproof hardware, > > > > The question of how to protect against someone with *physical* > > access certainly is more difficult, but surely that's a separate > > problem. > > Actually, that's a fairly simple problem (barring disassembling the > system and attaching a hardware debugger). You encrypt the root > filesystem and require a password to boot (See: LUKS). Debian has > built-in support for installing onto fs-on-LVM-on-crypt-on-RAID, and > it works quite well on all the laptops I use regularly. It's not > even much of a speed penalty; once you take the overhead of hitting a > 5400RPM laptop drive you can chew thousands of cycles of CPU without > anybody noticing (much). Then all you have to do is burn a copy of > your /boot with bootloader onto some read-only media (like a > finalized CDROM/DVDROM) and you're set to go.
Disconnect battery, and watch boot password go 'poof!'. Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/