interpreter lock doesn’t necessarily have to become a default enabled feature. That’s actually unlikely. Not sure yet.
On top of user / admin / superadmin boot modes, users who boot into user mode could choose to turn that user
user into a additionally restricted user (new term required also vs normal user
user). In such a mode the user would only be able to do a few things such as starting high risk applications. Or perhaps for example one mode would only allow to run Tor Browser but nothing else. Suppose the Tor Browser process would be compromised, the attacker couldn’t do much if we suppose /home/, /tmp, etc. noexec, interpreter lock, restricted shell, apparmor, sandbox, and whatnot. That would be similar to Chromium OS (which has interpreter lock) or Android. I.e. some users might choose to reduce the functionality of their VM in order to get better security.
Yes. The concept is good.
Though the actual implementation of
rbash at is quite limited
But maybe that could be improved. Perhaps such fixed restricted shells already exist.
The DISPLAY variable is just to start imagination. Maybe apparmor, sandbox, restricted shell or something could prohibit from setting the DISPLAY variable? Or some other environment variable? Or DISPLAY (or so) containing a random hash which cannot be guessed/find out by the attacker?