Re: [ANNOUNCE] Release Digsig 1.5: kernel module for run-time authentication of binaries

[Ulrich Drepper]

On 4/23/06, Arjan van de Ven <arjan@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/