> On 1999-04-10, "Theodore Y. Ts'o" <tytso@MIT.EDU> wrote:
>
> > From: "David L. Parsley (lkml account)" <kparse@salem.k12.va.us>
>
> >> 5) when the kernel exec's an elf binary, the effect is exactly as in
> >> my previous itteration:
> >> - checks capability flag (setuid 0) and if set uses caps + uid + gid
> >> from elf headers
> >> - if calling process has no caps, process runs with no caps
> >> - if calling process has elevated caps, kernel applies the
> >> permittable and inheritable cap flags from the binary (which can only
> >> be modified by the owner in any event)
>
> > Note that this means that if you boot a kernel which doesn't know about
> > this scheme (i.e. a 2.2 or a 2.0 kernel), then a binary which was
> > intended to have one relatively harmless capability (such as the
> > ability to bind ports below 1024, for example) and be setuid nobody,
> > would be interpreted by a kernel which didn't understand capabilities
> > as being setuid root. This is bad....
>
> Quite right.
>
> I'll say it again:
>
> who says the [root owned] +s, capability-enabled binaries need to be +x ?
^^^^^^^^^^^^
IMHO, that's the problem right there. In a true capabilities-based
system, it should be possible to have a cap-enabled binary which is owned
by another user, and may or may not be setuid. Using the sticky bit gives
us _very_ nearly complete capabilities support, as well as the same
compatibility benefits. The two real problems I've seen with the sticky
bit solution are both quite solvable, if we just _think_ about solving
them. I propose that, in a capelf hack enabled kernel, nfs mounts by
default don't honor the cap bit, much as they don't by default honor
setuid root. Same could go for user-mounted fs's on any media.
(requiring, say, 'CAP_SETFCAP' to mount w/ caps) For the 'older kernel'
problem, a user-space solution is probably sufficient.
> This gives you something that fits into existing fs semantics -- will work
> and be respected/protected over NFS (unlike +t which isn't protected on,
> say, your favorite IRIX NFS server),
Can be _very_ easily fixed, as above.
> doesn't nail you to a new filesystem
sticky bit doesn't
> or new binary format --
there's no reason older kernels can't run a cap-enabled binary, they just
won't run with any caps. (it should ignore the cap stuff) This is a good
thing.
> and is fail-closed if you were to boot a kernel
> that doesn't know about capabilities, copy/NFS share capability-enhanced
> bins to old systems, etc.
Very fixable, and should be fixed to get the enormous added benefits of
the sticky bit solution. We're talking about _real_ and _full_
capabilities support.
> Hank Leininger <hlein@progressive-comp.com>
>
- --
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/