lkml.org 
[lkml]   [1999]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: file effective and process inheritable mask
On Sun, 25 Apr 1999, Albert D. Cahalan wrote:
> Y2K writes:
> > On Sun, 25 Apr 1999, Albert D. Cahalan wrote:
> >> Y2K writes:
> >>> On Sat, 24 Apr 1999, Albert D. Cahalan wrote:
> > 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.
They whole deal is I'm claiming it is raising power it doesn't have, while
in the section you sniped you refered to it having power in pI. It was
supposed to be a "no kidding" obvious thing. You seemed to need the
obvious pointed out. I am trying to "deal" with it, by fixing it in a
useful manner.
> > 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
Totaly incompatible? Its more compatible to old behavior than the a. or b.
and if you look at the patch it can even be totaly compatible with b. via
settings in securebits .
> > 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.
Then why not just give them pP since any old admin tool to be useful is
going to raise them caps anyway. *Please* address that issue!! With the
"pure draft" standard you either get useless userland for admin purposes
or you get security holes. Under your system if a user shell has pI and
not pP and you want 'cp', 'dd',etc to be useful for admin purposes then
you might as have given the users shell those same caps in pP.
Do you not see that??!!
> > And you want to make the system more lenient!
> The default is (and always must be) traditional UNIX behavior.
Glad you agree that traditional unix behavior is important! Then the draft
doesn't work for you in a secure and traditional compatible fashion.
> >> 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.
Yes stricter than current but not strict enough in that pI is just a step
away to becoming pP in a useable system. It obviously is giving you a
false since of security or you really want to strongly break
compatibility.
Do you want to be able to use 'cp' or 'dd' in a cap-enhanced fashion or do
you just want to use newly made custom programs for these purposes?
You *can't* have it both ways with the draft formula.
Which way do you want??!!
Please do answer and either ackknowledge that you can't have it *both*
ways without making that draft formula more restrictive, or showing me
the errors of my ways!!
> 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.)
Great my patch offers compatibility with old behavior and if you are crazy
enough with the "pure draft" formula. securebits controls compatibility
and pP reduces the pI content that gets used to figure pP' .
> >> 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.
I do not see where you are getting that from. If the parent has the proper
pP and through its setting of pI it can gain whatever ability it needs.
It will never gain caps unlike your religious objections to anything
stricter than pP'=fP|(pI&fI) . You are so wrong about me needing to set fP
on 'mv' that it is painful. Why do you think I need fP to be set? I don't
think 'mv' should ever raise caps, you think it should.
> >> 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.
The draft to be secure requires that must of the common utils be made
unusable for admin purposes. You *have* to make new ones.
I have already talked about how "for untrusted admins" programs
shouldn't make its security decissions based on caps it has in its pI.
Caps, either my "soiled" or "pure draft" are the wrong answer if you don't
trust your admins.
No Kidding! -- Deal with those apples!

Then the question becomes what is the purpose of pI&fI being able to raise
caps that where not in pP. Answer None.

--
Warning:
When I mention capabilites I mean "soiled" capabilities not "pure draft".
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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.082 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site