[lkml]   [1999]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: file effective and process inheritable mask
    On Sun, 25 Apr 1999, Albert D. Cahalan wrote:
    > Y2K writes:
    > > On Sat, 24 Apr 1999, Albert D. Cahalan wrote:
    > >>> Yes I what to strengthen the formula not weaken it.
    > >>> pP'= (fP & x) | (fI & pI & pP)
    > >>> for proper files x can be ~0 otherwise 0 .
    > >> Your pP' fits into my equation as d_pP. (but it is broken)
    > > you think it is broken cause I think pI and fI should be strictly a
    > > limiting factor they should never cause a child process to gain caps the
    > > parent never had.
    > The parent _does_ have them, in pI.
    Ok if it has it in pI and not in pE or pP then it can't directly use that
    power(ie _*doesn't*_ have what it takes baby), it has to collude with say
    a friendly 'cp'.
    In another post I alluded to the fact that under your "pure" model you
    have either a useless 'cp' or a security hole 'cp'. Pick a process any
    process that has pI set has power to read/write every file on system but
    pP doesn't have it set.
    so instead of our process directly altering /etc/shadow you collude with
    'cp' ie. `cp /etc/shadow /foo/shadow` `evil-script /foo/shadow`
    `cp /foo/shadow /etc/shadow`
    or you can have cp and whole of user-land neutered then you have a
    "perfectly" secure system cause everything is so damn impotent.
    We make big huge monolithic programs instead cause using smaller tools
    together is now a big no-no. forget fileutils if you want to do anything
    you gotta compile a custum app-- no shell scripts for you little boy.
    shell scripts would be too hurtfull.
    And you want to make the system more lenient!
    > >> Notice that my equation is _not_ the pP equation from the draft.
    > >> The draft produces d_pP, and o_pP is something lenient.
    > >> They are combined using a configurable mask.
    > > I don't want lenient,
    > Any useful system allows a full range of behavior, from lenient to strict.
    > The system I proposed would calculate both lenient and strict values,
    > grant the strict values, and then add a configurable set of bits from
    > the lenient values.
    > > I want more strictness on how caps are gained
    > > ie. through fP *only* .
    You are already way too lenient on raising caps and you simply purpose
    that we become more lenient.
    > That is _less_ secure, because damn near everything needs to have bits
    > set in fP.
    For a few not "damn near everything" for the *special* programs that raise
    caps -- the suid-roots of today.
    You'll have to bit mark everything with fI to be usefull for admining
    which causes things to raise like hell so completely destroys fI and PI
    ability to simply act as filters-- cause you have them overloaded in a
    dangerous way. Under my system you don't fP 'cp' to raise caps but you
    have to set insecure settings for fI on 'cp' if you want it to be useful.
    All the fileutils become quasi-suid-root . That is broken.
    The alternative is to make most everything useless for admining and have a
    few fat special purpose admin program that do everything without using any
    externel general purpose utilities. Or maybe worse you could have a
    shitload of little tiny do-little special custom programs.

    Under my proposal you give most(hopefully all) binaries an elf cap header
    that filter caps from spreading. You mark a very select few programs the
    ability to raise caps. Right now you can use the compatibile behavior of
    suid-root to raise all caps then complement that with elf header
    restrictions to get a workable system RSN. With ext3 you would put things
    in there to raise in a more fine-grained manner.
    The suid-roots would be the first tier of programs that I'd propose
    elf-heading. That would be a huge boon in security right there.
    Second tier would be the daemons currently running as root.
    Third tier would be most of the other system utils and stuff that might
    be used by cap-enhanced programs to do things.
    Forth tier would be most other programs that people might create just for
    their own accounts.
    > The other proposal (mark the parent, so that bits are dropped from pI)
    > is much easier to use and more compatible.
    Great I purpose the very sensible solution that you mask off pI with the
    current pP... Oh wait you already heard that one.

    Warning when I mention capabilites I mean "soiled" capabilities not "pure".
    Any caps I mention are *derived* from a withdrawn draft posix document.

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