lkml.org 
[lkml]   [1998]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectLinux-privs

    On Sun, 29 Mar 1998, Alan Cox wrote:

    > This is capabilities, this is NOT what BSD securelevels are. There was
    > a Linux capabilities project. It never got merged, it died AFAIK.

    well, judging from lurking on their list and checking out patches
    casually, it got completed to quite a level. suser() got extended in a way
    to check for priviledge(s) required by the local kernel context. They also
    got it fairly close to TrustedSolaris. The funny thing is that with their
    scheme, a has_cap(CAP_RAWDISK) is about 3 lightweight assembly
    instructions, about the same as you get from the broken BSD 'if
    (securelevel > 0)' approach. [a has_cap(CAP_RAWDISK) expands to something
    like a 'if (current->capmask & CAP_RAWDISK)']. And if you consider that
    suser() is removed _completely_ [from that source point, it's still there
    for migration reasons], it's even a speedup ...

    The capabilities patch was quite migration-friendly last i checked, they
    also fully contentrated on getting the 'full root'->'finegrained
    capabilities' transition as smooth as possible [by allowing a 'mixed mode'
    security setup, where part of the system uses capabilities, and part of
    the system still uses the 'legacy' root capability. Setuid root basically
    means a fully-ones capability mask at exec() time.]

    So it was really low-impact and nicely designed, i think Theodore T'so has
    had the plan to merge it? There was a patch against a 2.1.5x-ish kernel
    some time ago. I'm quite sure he has not forgot about that patch.

    the capabilities patch needs about as much care and knowledge to integrate
    as a securelevel approach, but it's inherently more flexible. (what does
    it mean anyway to have secure 'levels'? what do we level there, security
    is not quite a thing that is a relation, IMHO it's rather a set of
    'possibilities', with no particular connections between these
    'possibilities'). I think there is no need to blindly follow the
    military's rigid command hierarchy in Linux. (this is where that 'level'
    stuff came from originally). I even dare to say that the capabilities
    approach is much more intuitive than a suser()+securelevel approach, from
    the maintainance point of view.

    -- mingo


    -
    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.019 / U:29.736 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site