> 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'.
No kidding! Deal with it.
> In another post I alluded to the fact that under your "pure" model you
The draft is not pure capabilities. You are using the wrong terms again.
a. pure capabilities Something insane, with NO FILESYSTEM NAMESPACE
b. POSIX draft Linux and other systems mostly support this
c. your proposal Totally incompatible capability list system
> 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.
There should be very few of these. Normal users don't get such processes.
> And you want to make the system more lenient!
The default is (and always must be) traditional UNIX behavior.
>> 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.
>
> You are already way too lenient on raising caps and you simply purpose
> that we become more lenient.
The draft specifies how capabilities should work. You call this "lenient",
but it is far more strict than the existing system.
I propose two things:
1. per-bit selection of traditional and draft behavior
2. David's bit set that reduces pI content
Without reasonable compatibility, we will _never_ see a Linux distribution
with enhanced security features. (meaning Debian, Red Hat, etc.)
>> 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.
Nope, because you don't let fI and pI work as they should. You have to
set fP bits on /bin/mv and add some kind of user checking to /bin/mv too.
>> 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.
Nope, that is crap. An admin's shell might have nothing in pP, so you
would need to set fP bits on damn near everything.
-
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/