lkml.org 
[lkml]   [1998]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 2.1.97] more capabilities support
       Date: Sun, 26 Apr 1998 01:27:11 +0200
    From: Andrej Presern <andrejp@luz.fe.uni-lj.si>

    > How about the fact that in order to do pure capability systems, you'd
    > have to rev the interface of every single system call to take a
    > capability argument (just as file I/O syscalls now take a file
    > descriptor)?

    An example use of such a basic and primitive extension would be that a
    suid program can throw away its authority to execve() system call, if it
    doesn't need it.

    Huh? That's hardly a pure-capability system. In a pure capaibility
    system, you have something that is effectively like a "key", which can
    get passed around between processes, and a privileged program is merely
    a program that has several keys that confer more abilities than the
    standard default capability.

    Using the lock/key anaology, though, having a key doesn't mean that when
    I walk towards a locked door (with a bad guy following behind) that the door
    will automatically open. I have to explicitly take out the key
    (capability) insert it into the lock (pass the capaibility to the
    Trusted Code Base) and use the key before it does any good.

    This is the argument for why pure capability systems are better, because
    it means that it's much harder to trick a privileged program into doing
    something it shouldn't during its course of routine operations, since
    (for example) it would pass a highly privileged capability to the
    creat() system call when creating a temporary file in /tmp. This
    instantly eliminates entire classes of security holes. It also makes
    the system completely unlike Unix. (And of course, capabilities still
    don't help you you against stack overrun attacks.)

    Your scheme of simply throwing away authority is something that you can
    do using the POSIX capaibility system, and in fact you can do it today
    with the current 2.1.x system.

    In any case, Alexandar Kjeldaas pointed out (and I completely agree with
    him), system calls are completely the wrong level of granularity for
    capabilities. Execve() is perhaps the only system call where it might
    be interesting, and even there, you might want the ability to exec a
    non-privileged process, but not a privileged one. Throwing away the
    ability to open any file is almost certainly not going to be useful, but
    restricting the ability to bypass the normal permissions checks while
    opening files would be useful.

    - Ted

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu

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