Messages in this thread | | | Subject | Re: [2.7 "thoughts"] V0.3 | From | Valdis.Kletnieks@vt ... | Date | Fri, 10 Oct 2003 18:05:47 -0400 |
| |
On Fri, 10 Oct 2003 15:17:30 MDT, Uncle Jens said: > What about some type of kernel-based-DRM, where only properly(trusted) signed > binaries can be executed? For example, I could compile my public key in with > the kernel and it would only run binaries that had been signed by my private > key. I feel that this would be a great security enhancement and would like t o > hear about any issues this may present. > I've searched all over for a project that does something like this and have b een > unable to find one. I'd like to start one up on my own, but lack the kernel > development expertise. > > I'm open for any input/flames/etc....
There are two basic problems with the idea:
1) It does nothing to prevent any of the usual abuses of a system - buffer overflows, shellcode, and the like. You get fed a bad packet, the signed Apache binary overflows, and executes the signed /bin/sh that then calls the signed /bin/echo to append stuff to the appropriate files to create a back door.....
2) Unless you're working with a kiosk/embedded system where the number of binaries is quite small, you're looking at a maintenance headache (remember, if you blindly sign binaries without auditing every single one, you're really not doing anything useful...)
A *much* better approach would be to do the following:
1) Mount everything either 'read only' or 'noexec', and use something like LSM to make sure it doesn't get remounted. So binaries off /home won't run, and binaries on /usr can't be trojaned (barring OTHER breaches such as remounting, or scribbling on the raw disk, etc...)
2) Fix the bypasses of noexec (like '/lib/ld-linux.so.2 /your/binary/here').
That's probably a much better way of addressing the "running unauthorized binaries" threat, without taking a crypto signature hit on every exec()..... [unhandled content-type:application/pgp-signature] | |