OK I’m going to go ahead and post this in the hopes it forces me to finish the series. Check back for updates. Not going to be this weekend, but by next weekend I promise. I’ve had the thoughts saved since I started part 1, but things kinda went awry (marriage, and then things just went downhill from there ). Regardless here is a teaser of the final segment of the series. BTW, if you guys actually cared you woulda hounded me to finish. Still, I promise I’ll finish up this segment this week.

Now back into the role of glibc. The role of glibc was defined well before mature mandatory access controls like SELinux came into the Linux picture. It was defined in a general fashion that allowed it to be extended by a few userland modifications and of course the kernel support discussed in the last article.

__libc_enable_secure in rtld.c (responsible for most of the runtime linking environment cleansing)

-How does SELinux solve this problem?
-I will delve into the details… security_bprm_secureexec in binfmt_elf.c
-AT_SECURE actually enforced by glibc elf/dl-support.c and elf/dl-sysdep.c
-Static apps have no problems (aside from the usual problems)
-The linker is the only _real_ threat for dynamically linked apps.
-OK so the people that implemented SELinux were smart so we’re safe right?
-Delve into problems with shell scripts, interpreted code, etc