Messages in this thread | | | Date | Fri, 9 Apr 1999 20:10:50 -0400 (EDT) | From | "Theodore Y. Ts'o" <> | Subject | Re: caps in elf, next itteration (the hack get's bigger) |
| |
Date: Fri, 9 Apr 1999 17:48:14 -0400 (EDT) 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....
The only way to solve this is to have the kernel, when you set any capabilities using this scheme, mutate some other portion of the ELF header so that a kernel that doesn't understand this new format will refuse to run the binary.
The prospect of having the kernel having the capability to read *and* modify ELF sections still does bother me as putting way to much complexity into the kernel, though. Especially the prospect of adding a new ELF section --- that's really not something you want to do in kernel mode....
- Ted
- 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/
| |