Re: file effective and process inheritable mask
Y2K (y2k@y2ker.com)
Sun, 25 Apr 1999 12:50:45 -0700 (PDT)
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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/