On Sun, 25 Apr 1999, Albert D. Cahalan wrote:
> I propose two things:
>
> 1. per-bit selection of traditional and draft behavior
erm, did I miss something here? Can you bring me up to speed on what this
is?
> 2. David's bit set that reduces pI content
what about 3. fm=min caps to run else EPERM ?
> Without reasonable compatibility, we will _never_ see a Linux distribution
> with enhanced security features. (meaning Debian, Red Hat, etc.)
Agreed. It needs good compatibility and easy transition.
[snip remainder]
Just to be sure I'm not completely off base here, this is what it looks
like to me for current file cap sets (5 total):
fP, bits explicitly raised in Permitted
fI, bits Inheritable from parent
fE, Effective bits initially set (yes, I agree we should go ahead and
include this full set)
fM, inheritable Mask, this adds security by restricting pI from always
passing unrestrained to the child
fR, (suggested nomenclature) Required capabilities; i.e., if the parent
process doesn't have the necessary pI for the child to run properly, it
fails with EPERM. This would occur, for example, when a normal user tries
to execute a system service which needs to inherit certain bits to run,
such as CAP_NET_BIND_SERVICE. This also has the potential to protect from
certain DoS attacks, and shortcuts ugly error conditions.
I'm curious, though, where everybody stands on setuid0 vs. ext2 bit. To
summarize:
setuid0
pros:
- (nearly) perfect for current setuid-root binaries
- (mostly) secure operation over nfs
- easily recognizable
- works great with current tools (tar, rpm, cp, ...)
cons:
- I'm not sure about the best solution for binaries w/ pP=0 and
pI=(something); if this needs to be priviledged, it means marking a lot of
stuff like tar, cp, rpm, ... setuid0; if this is not a priviledged
operation, the file owner can raise all inheritable; this is especially a
hazard for binaries which are setuid to some non-root uid (a good thing to
do for filesystem security)
- for files marked setuid0, requires storing uid info in headers
ext2bit
pros:
- works great on local elf binaries; IMO it is logically equivalent to
actual caps in fs metadata
- compatible w/ current tools (cp, tar, rpm) by a /proc settable
mapping of the ext2bit to the sticky bit. (for files)
- can be used over nfs by honoring the sticky bit (bad security)
cons:
- not inherently safe over nfs, requires the admin to insure security by
other means.
- tool compatibility is a bit hackish, though workable
comments?
cheers,
David
- --
David L. Parsley
Network Specialist
City of Salem Schools
-
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/