lkml.org 
[lkml]   [2006]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2006-04-23 18:41    [W:0.028 / U:0.008 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site