Re: [PATCH v1 0/7] Remove in-tree usage of MAP_DENYWRITE

David Hildenbrand
2021-08-12T12:47:54Z

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