On 12.08.21 14:20, Florian Weimer wrote:
* David Hildenbrand:There are some (minor) user-visible changes with this series: 1. We no longer deny write access to shared libaries loaded via legacy uselib(); this behavior matches modern user space e.g., via dlopen(). 2. We no longer deny write access to the elf interpreter after exec completed, treating it just like shared libraries (which it often is).We have a persistent issue with people using cp (or similar tools) to replace system libraries. Since the file is truncated first, all relocations and global data are replaced by file contents, result in difficult-to-diagnose crashes. It would be nice if we had a way to prevent this mistake. It doesn't have to be MAP_DENYWRITE or MAP_COPY. It could be something completely new, like an option that turns every future access beyond the truncation point into a signal (rather than getting bad data or bad code and crashing much later). I don't know how many invalid copy operations are currently thwarted by the current program interpreter restriction. I doubt that lifting the restriction matters.3. We always deny write access to the file linked via /proc/pid/exe: sys_prctl(PR_SET_MM_EXE_FILE) will fail if write access to the file cannot be denied, and write access to the file will remain denied until the link is effectivel gone (exec, termination, PR_SET_MM_EXE_FILE) -- just as if exec'ing the file. I was wondering if we really care about permanently disabling write access to the executable, or if it would be good enough to just disable write access while loading the new executable during exec; but I don't know the history of that -- and it somewhat makes sense to deny write access at least to the main executable. With modern user space -- dlopen() -- we can effectively modify the content of shared libraries while being used.Is there a difference between ET_DYN and ET_EXEC executables?
No, I don't think so. When exec'ing, the main executable will see a deny_write_access(file); AFAIKT, that can either be ET_DYN or ET_EXEC.
-- Thanks, David / dhildenb
