* Andy Lutomirski: > Can’t an ELF note be done with some more or less ordinary asm such > that any link editor will insert it correctly? We've just been over this for the CET enablement. ELF PT_NOTE parsing was rejected there. I don't think binutils ld has a way to set an ELF program header it doesn't know anything about. >>> Would enterprise distros consider backporting such a thing? >> >> Enterprise distros aren't the problem here because they can't remove >> vsyscall support for quite a while due to existing customer binaries. >> For them, it would just be an additional (and welcome) hardening >> opportunity. >> >> The challenge here are container hosting platforms which have already >> disabled vsyscall, presumably to protect the container host itself. >> They would need to rebuild the container host userspace with the markup >> to keep it protected, and then they could switch to a kernel which has >> vsyscall-unless-opt-out logic. That seems to be a bit of a stretch >> because from their perspective, there's no problem today. >> >> My guess is that it would be easier to have a personality flag. Then >> they could keep the host largely as-is, and would “only” need a >> mechanism to pass through the flag from the image metadata to the actual >> container creation. It's still a change to the container host (and the >> kernel change is required as well), but it would not require relinking >> every statically linked binary. > The problem with a personality flag is that it needs to have some kind > of sensible behavior for setuid programs, and getting that right in a > way that doesn’t scream “exploit me” while preserving useful > compatibility may be tricky. Are restrictive personality flags still a problem with user namespaces? I think it would be fine to restrict this one to CAP_SYS_ADMIN. Thanks, Florian
