Messages in this thread | | | Subject | Re: file effective and process inheritable mask | Date | Mon, 26 Apr 1999 11:31:00 -0400 | From | Horst von Brand <> |
| |
"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.
> 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"
> 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
> - 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?
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... -- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
- 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/
| |