Re: inheritable set [was Re: caps in elf headers: use the sticky bit!]

Raul Miller (rdm@test.legislate.com)
Sun, 25 Apr 1999 14:32:45 -0400


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
> which weren't designed to cope with those privs. You _can't_ change
> that while maintaining compatibility. It's a simple one way choice:
> compatibility necessarily implies preserving an entire class of security
> vulnerabilities.

This is worth expanding on.

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].

"Protection" typically means denial of service and/or logging.

#1 is almost a no-brainer. In most circumstances you want some level of
this [then again, determining how much and what flavor of this kind of
protection to use can get interesting.] It's a safe bet that you want
to make it so breaks here don't grant complete power over the system.

#2 is a more rarified circumstance. Most systems are single user
(this is, in general, more secure than multi-user). Usually, getting
#1 right is more important (non-networked machines are something of
an exception), but this is still important.

#3 starts getting into the area of pyrrhic victories. There's nothing
technology can do to protect the system from its administrator. However,
in a multi-administrator environment there are things you can do to
cripple the individuals (acting alone) and you can certainly do things
to help people keep an eye on each other.

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.

-- 
Raul

- 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/