Messages in this thread | | | Date | Mon, 12 Apr 1999 11:34:21 -0400 (EDT) | From | "David L. Parsley (lkml account)" <> | Subject | Re: caps in elf, next itteration (the hack get's bigger) |
| |
On Mon, 12 Apr 1999 linux-kernel@progressive-comp.com wrote:
> 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/
| |