[lkml]   [2002]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] remove sys_security
    On Fri, 18 Oct 2002 09:28, Alexander Viro wrote:
    > As for "highly secure"... Could we please
    > see some proof? Clearly stated properties with code audit to verify them
    > would be nice.
    > I'm yet to see a single shred of evidence that so-called security
    > improvements actually do improve security (as opposed to feeling of
    > security - quite a different animal). And in this case burden of proof is
    > clearly on your side.

    Some people at IBM are working on analysis of SE Linux policy to prove that it
    does what it is supposed to do. The benefits of MAC as a general concept are
    well documented.

    For real-world examples of the benefits of SE Linux:

    With the recent terrible PAM bug, in a default Debian setup you could login as
    "man" and then replace the man program (owned by user "man") with a trojan
    (and wait for root to read a man page). With a default SE Linux setup the
    man binary is in bin_t and the default SE Linux role (which is applied to the
    "man" account) is not permitted to write to it. Of course setting the file
    to be immutable or configuring the man-db package for the man program to not
    be SUID would get the same result, but that's not generally done. Also it
    should be noted that there's an infinite number of potential attacks,
    removing access that's not needed is the best way to address them.

    The recent Apache SSL exploit gave attackers the full access rights of the
    Apache process, and the recent scoreboard Apache bug allowed someone who can
    write to Apache data the ability to send a signal to any process. Taking
    advantage of both bugs a remote attacker could send a signal to any process
    (including root). With SE Linux Apache only gets control over it's own
    cgi-bin scripts and it's own processes. It can kill itself and some of it's
    children, but that's all. It can't interfere with other daemons or user

    After the recent ssh bug the default SE Linux policy was changed to not allow
    sshd_t to transition directly to priviledged domains. So the next time sshd
    is broken the worst you can do with a default SE Linux machine is to login as
    user_r (which allows you to kill any user processes and write to any user
    files but not kill daemons, change system configuration, or read
    /etc/shadow). You could configure a SE Linux system to have ssh log you in
    with a role that is only allowed to transition to the real role (which
    requires password authentication) not actually do anything useful. So then
    if sshd is cracked the attacker can't directly do anything useful. Of course
    this still wouldn't solve the problem of sshd being trojaned...

    -- My NSA Security Enhanced Linux packages Bonnie++ hard drive benchmark Postal SMTP/POP benchmark My home page

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:30    [W:0.040 / U:4.600 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site