Messages in this thread | | | Date | Sun, 23 Apr 2006 09:38:34 -0700 | From | "Ulrich Drepper" <> | Subject | Re: [ANNOUNCE] Release Digsig 1.5: kernel module for run-time authentication of binaries |
| |
On 4/23/06, Arjan van de Ven <arjan@infradead.org> wrote: > does this also prevent people writing their own elf loader in a bit of > perl and just mmap the code ?
You will never get 100% protection from a mechanism like signed binaries. What you can get in collaboration with other protections like SELinux is another layer of security. That's good IMO. Not being able to slide in modified and substituted binaries which then would be marked to get certain privileges is a plus.
But preventing every type of code loading or generation at userlevel cannot be prevented this way. Just look at the code proposed to deal with execmem problems in http://people.redhat.com/drepper/selinux-mem.html. This is with all the SELinux mechanisms in place and activated. You can prevent by using the noexec mount option for every writable filesystem. But this is so far not possible for ordinary machines. There are widely used programs out there which need to dynamically generate code.
Signed binaries are therefore a complete solution only for a very limited number of situation. For embedded systems I see this but here we also have the "Tivo problem" where devices are built on top of Linux and people are still prevented from extending/modifying them. Beside that there is potentially some locked down machines with limited functionality which can use it (e.g., DMZ servers, but they mustn't use Java etc).
So, I do not think that signed binaries have a big upside. And they have a potential big downside. The better approach to ensure that SELinux, for instance, doesn't change the labels for incorrect binaries is to integrate restorecon etc with the package manager and have functionality in the package manager to recognize incorrect binaries. This might again mean signed binaries although I imagine the current signed hash values work fine, too. Although we might want to go from MD5 to SHA256.
I have been working on signed binaries at some point myself but abandoned it after realizing that it realistically only can be misused. If I'd have a vote I'd keep this stuff out of the kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |