[lkml]   [1999]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: caps in elf, next itteration (the hack get's bigger)
    On Wed, 14 Apr 1999, Ingo Molnar wrote:

    > no. This is a misconception. The point is to reduce the power of
    > actually executing security-relevant code, thus reduce the chance of a
    > system compromise. Having some sort of (mostly inactive!) super-user
    > around in the migration period is not at all broken. The point is to
    > get rid of random setuid root binaries (ping, traceroute, etc.) and
    > system daemons (klogd, syslogd, lpd, etc.) executing with full system
    > priviledges. A considerable percentage of those binaries needs only a
    > small subset of system priviledges. We do _not_ want to remove the
    > administrator, that is a different task.

    Thoughts for the day:

    What capabilities will we want? Will they be defined by the admin
    themselves, or will it be a full set of capabilities available to the

    What I'm concerned about is that if we go ahead and build a capability
    enabled system, and then those POSIX boys go and define their own idea of
    a capability system, these two could prove to be incompatible. That would
    be a disaster. Have the POSIX people actually defined the capability
    standards yet? If not (or if they are in the middle of deciding that),
    there's NO point in doing anything UNTIL we have a STANDARD that all
    UNIXes will conform to. And then there's the question of capabilities over
    shared networked filesystems (especially on a network populated by
    different UNIX systems).

    Looking over the discussions on this subject for the past week or so, it
    looks like we're trying to kludge capabilities into Linux. I especially
    don't like the suggestions that capabilities be built into the filesystems
    - this has the potential to make it completely unportable to different
    filesystems (i.e trying to run Linux off NTFS for example 8)

    One potential answer might be *firstly* define a newer ELF standard that
    is completely incompatible with the current ELF standard which will ensure
    that older kernels booted on a capability-enhanced system will NOT be able
    to run ANYTHING, thus closing that security hole, and *secondly*
    capability-ehanced kernels SHOULD not be able to run older ELF binaries.
    Then we can properly encode capabilities into the binaries, yet enforce

    I like this idea. A lot. Hey, if we're gonna break free from the past,
    let's go the whole hog and add in ACLs too. We do want that A1/B1 security
    rating, don't we? 8) We all know Microsoft has lost to us, but we haven't
    really won against certified operating systems such as VAX/VMS.

    Ah, this thought just hit me just now. What we're trying to do is clone
    VAX/VMS!! 8)

    /\_/\ Legalise cannabis now!
    ( o.o ) Grow some cannabis today!
    > ^ < Peace, Love, Unity and Respect to all. - Now back in the United Kingdom!

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

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