The Linux Security Journey — Secure Execution Mode

In general, a binary is executed in “Secure Execution Mode” in case the “AT_SECURE” entry of the auxiliary vector (https://medium.com/@boutnaru/linux-the-auxiliary-vector-auxv-cba527871b50) contains a non-zero value. They are different cases that causes this value to be non zero such as: a LSM (https://medium.com/@boutnaru/linux-security-lsm-linux-security-modules-907bbcf8c8b4) has set the value, the “real uid” (https://medium.com/@boutnaru/the-linux-security-journey-ruid-real-user-id-b23abcbca9c6) and the “effective uid” (https://medium.com/@boutnaru/the-linux-security-journey-euid-effective-user-id-65f351532b79 ) of the task/process differ (and the same for the groups values), a non-root user executed a binary which conferred capabilities to the process (https://man7.org/linux/man-pages/man8/ld.so.8.html).

Overall, secure execution mode is a feature of the dynamic linker/loader. In case it is enabled specific environment variables are ignored when executing a binary. Examples of such variables are: “LD_LIBRARY_PATH”, “LD_DEBUG” (unless /etc/suid-debug exists), “LD_DEBUG_OUTPUT”, “LD_DEBUG_WEAK” (since glibc 2.3.4), “LD_ORIGIN_PATH”, “LD_PROFILE” (since glibc 2.2.5), “LD_SHOW_AUXV” (since glibc 2.3.4) and “LD_AUDIT” (https://manpages.ubuntu.com/manpages/focal/en/man8/ld.so.8.html) — as shown in the screenshot below.

Lastly, the goal of the secure execution mode is to block the ability of causing a binary which can be executed with “setuid”/setgid” to load/executed arbitrary code and thus perform a privilege escalation (due to the fact it is executed by one user but executed with the permissions of another user which case also be root).

See you in my next writeup ;-) You can follow me on twitter — @boutnaru (https://twitter.com/boutnaru). Also, you can read my other writeups on medium — https://medium.com/@boutnaru. You can find my free eBooks at https://TheLearningJourneyEbooks.com.