On 09.07.2011 20:08, Thor Lancelot Simon wrote: > However, I'd like to see a different system call used to enter the chroot > in this case, so that it's possible to have a normal, less-restricted > chroot at the same time.
IMHO that will defeat its purpose: programs will have to get patched to call some sort of securechroot(2). Everything outside of base (or patched pkg) won't benefit from it. In case it gets turned into a syscall, I would suggest a "security.models.securechroot.override" that would override chroot(2) confinement rules and make securechroot(2) == chroot(2). Override may be explicitly turned off in specific circumstances (like kernel tables manipulation for a chroot'ed process), but this would have an impact on the whole system. Ideally, this would have to be specified on a per executable basis (like PaX flags), but heh... wishful thinking. More buttons, levers, knobs. -- Jean-Yves Migeon [email protected]
