lkml.org 
[lkml]   [1999]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: file effective and process inheritable mask
Date
From
"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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.054 / U:0.572 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site