Messages in this thread | | | Subject | Re: [PATCH v1 0/7] Remove in-tree usage of MAP_DENYWRITE | From | David Hildenbrand <> | Date | Thu, 12 Aug 2021 14:47:46 +0200 |
| |
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
| |