Messages in this thread | | | Subject | Re: caps in elf, next itteration (the hack get's bigger) | Date | Sat, 10 Apr 1999 21:18:22 -0400 | From | Horst von Brand <> |
| |
"David L. Parsley (lkml account)" <kparse@salem.k12.va.us> said: > OK, I think I know a good way to improve 3 aspects of my previous > solution:
[...]
> 1) 'setuid 0' is _just_ a filesystem flag that alerts the kernel to a > program that has capabilities + uid + gid in the elf headers. (putting > uid & gid in the headers was Albert's idea, and now seems to me a must)
Current tools won't recognize a file belonging to jschmoe as hers, quotas will go haywire too.
[...]
> 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)
When old kernel executes program that has just the capability to bind to a low port, it is now suddenly all-powerfull...
This kind of idea _mandates_ at _least_ a new executable format all around. Remember the a.out --> ELF pain? The screwups libc5 --> libc6? And all to ease/postpone the pain of introducing capabilities into the FS? No, thanks.
> I _think_ this covers all the bases to give us a very flexible and > UNIX-ish capability system for elf binaries, but I won't go as far as > calling this a 'final' itteration yet. Add the notion of user cabilities > granted by 'login' from /etc/shadow or wherever...
Any ACL system is inherently distinctly un-Unix-ish, IMHO. Better bite that bullet once now and get it over with. -- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viña del Mar, Chile +56 32 672616
- 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/
| |