Re: inheritable set [was Re: caps in elf headers: use the sticky
Y2K (y2k@y2ker.com)
Sun, 25 Apr 1999 14:11:56 -0700 (PDT)
On Sun, 25 Apr 1999, Raul Miller wrote:
> On Wed, 21 Apr 1999 13:39:09 -0700 (PDT), Y2K <y2k@y2ker.com> said:
> > > Thats not very compatible, right now if the parent has the caps they flow
> > > to their children.
> Stephen C. Tweedie <sct@redhat.com> wrote:
> > Right. That's the entire point: automatic inheritence of all caps is a
> > potential security problem, as it lets privileges leak into programs
> This is worth expanding on.
I think that it was a job expanding on it.
> There are (at least) three kinds of security issues being discussed in
> these thread:
> (1) protecting system from outside attack. [From script kiddies, etc.]
> (2) protecting system from inside attack. [From legitimate users,
> or someone who broke #1]
> (3) protecting system from administrative attack [from legitimate admins
> or someone who broke #2].
> #3 starts getting into the area of pyrrhic victories.
> Anyways, fine grained priviledges can certainly be a useful tool for
> managing #1 and #2, but they don't need to be in the file system for that.
> Putting priviledges in the file system helps on #3, exactly because it
> guarantees that none of the standard administrative tools work.
I don't like the idea of completely sacrificing standard practices like
the use of file utils and shell scripting on the alter of "pure" caps.
And to boot I think it is misguided. Most of these new utils that
would have to be made anyway should contain policy that the kernel
shouldn't even care about. There is a often a poor match between the caps
needed to exercise that policy and what the policy actually is. What does
the fact that I want to implement the policy that user 'suzy' can users to
the system in a controled fashion maybe uid has to be an unused uid
greater than 1000, name has to be fit a certain site standard, can assign
to a few groups etc. It also adds extra infomation in another file so he
can later reassign groups or delete old users. 'suzy' and her assistant
'bob' can temporarily suspend users whose uid is greater than 1000
additionialy 'bob' can't suspend 'suzy';-> Add all the other files in
/etc/ that might need policies based on who can do what exactly to what
parts of different files. My point being that for these it is plainly
absurd to make the security decisions based on any particular set of caps.
#3 is best served by very carefuly writing either one or a series of admin
programs that is cap enhanced by fP. Maybe they should take a look at
linuxconf and add lots of policy to it.
Neither "soiled" or "pure" caps has any real direct benefite to these
people.
--
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/