> > Ignoring AT_SECURE, LSMs likely will need a say in whether that ORIGIN > > thing gets honored or not introducing yet another vector where this can > > be overriden or ignored. > > > > Also, we change long-standing kernel behavior which will be very > > surprising for any userspace that might implicitly rely on the fact that > > the system loader is used. So even if we were to do something like this > > it would very likely have to be configurable in some way. > > I think the proposed patch will only change behavior if the > interpreter path starts with "$ORIGIN"? That wouldn't work on existing > kernels unless you have a directory literally named "$ORIGIN" in the > cwd, because "$ORIGIN/..." would be interpreted as a normal relative > path.
I was thinking: You download a bunch of $ORIGIN binaries into /woot on a kernel that doesn't support $ORIGIN. You forget about /woot and update your kernel. You have no idea that kernel behavior has changed to allow $ORIGIN to work for the loader. You remember /woot exists and are starting to execute binaries under the assumption that $ORIGIN is purely a userspace concept applicable to shared libraries. /woot came with a malicious loader and it suddenly gets used - if that happens in a sandbox noboday cares. Now that $ORIGIN works and no sandbox might be needed I think enabling $ORIGIN might still end up with funny surprises.
