> 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 ?
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), doesn't nail you to a new filesystem
or new binary format -- 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.
Hank Leininger <hlein@progressive-comp.com>
-
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/