On Mon, 26 Apr 1999, Horst von Brand wrote:
> "David L. Parsley (lkml account)" <kparse@salem.k12.va.us> said:
>
> [...]
>
> > 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
>
> How about passing _only_ the caps in effect when doing an exec(2) to the
> child, fI on that allowing? This gives the effect of fM, but finer-grained.
By caps in effect, do you mean pP or pE? In any event, a capability-aware
program should certainly twiddle it's caps appropriately before an exec.
fM mainly gives some control to the admin/system designer, and gives us a
cheap security method without patching the binaries to make them fully
capability aware. I'm guessing it'll be a _long_ while before most system
programs are cap-aware. fM is a big help in the absence of a
non-cap-aware binary.
> > 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.
>
> It would almost always be "none at all": Witness "foo --version"
OK, so a user without enough pI to execute the program now can't get the
version number. This doesn't really bother me. Of course, many programs
won't require this setting at all. In any event, I'll admit I'm still not
fully convinced of the _necessity_ of this feature, though I can see where
it could be useful.
> > 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
>
> Not 100% equivalent, as this means setting _one_ bit in the FS gives
> (unknown!) capabilities that reside inside the file. Doesn't work at all
> for non-ELF executables
Whomever sets the one bit really should check the caps in the file first;
I agree there's a difference here. An admin that cap-enables a
file without knowing the contents is just as unwise as one who
marks files setuid-root willy-nilly. Ideally admin will do in two steps
what should otherwise be done in a single step; assign caps to file, then
cap-enable, as opposed to assign & enable in a single step (fs metadata).
Once the caps are read for the file, everything else operates as it
should. And yes, this only works for ELF.
> > - 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
>
> - Stands in the way of doing it properly (in the FS) later: What do you do
> with ELF-marked capable executables when the capabilities now reside in
> the FS?
The kernel should honor real fs-caps in preference to cap-elf, and it
should be trivial to create a conversion utility which:
- checks all files for being cap-enabled
- reads the caps from the headers then removes them
- stores them properly in the fs
Now it's done right, and the binary behaves _exactly_ as before. (except
you'd better patch tar, rpm, dpkg, cp, mv, ... before taking this step)
> I dont see the "compatible with current tools" at all here, and I don't see
> the needed (re)design of the userland tools and procedures either...
Well, without being patched, 'tar' and friends will not store capability
data from the fs metadata; it only gets uid, gid & mode info. In this
mode info it also stores the (useless for files) sticky bit, which can be
mapped in the kernel to the cap-enable bit (so with this compatibility
enabled, the kernel ignores the original value of the sticky bit for
files). I'm saying this should be /proc settable. This way, admin can
use 'echo 1 > /proc/.../captoolcompat' and 'echo 0 > ...' before and after
any tar, rpm, dpkg, what have you that should preserve capabilities. It
may even be safe to leave this on most of the time.
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/