Messages in this thread | | | Date | Fri, 9 Apr 1999 20:28:27 -0400 (EDT) | From | "David L. Parsley (lkml account)" <> | Subject | Re: caps in elf, next itteration (the hack get's bigger) |
| |
On Fri, 9 Apr 1999, Theodore Y. Ts'o wrote:
> 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....
OK, but if you're running a kernel that doesn't understand this hack, how do you give a process only the ability to listen on low ports? In the absence of the 'cap flag'=setuid 0, old inheritance behavior will still apply; with this hack and a non-setuid binary, the permitted and inheritable parts can still be used. (ref my ideas in 'caps in elf next (final?) itteration')
> 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.
Eh, it would just fall back on the crummy older behavior. Without 'setuid 0' it would have _no_ privs, with it set it would get all...
> 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....
Well, sure, that's a bit ugly; I just feel that the benefits outweigh the drawbacks.
> > - Ted >
- -- 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/
| |