Messages in this thread | | | Date | Mon, 12 Apr 1999 09:53:14 -0400 | From | linux-kernel@progress ... | Subject | Re: caps in elf, next itteration (the hack get's bigger) |
| |
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 ?
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/
| |