This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch 0/3] Live PIDs with deleted files by /dev/PID/mem


On Sat, 2014-02-22 at 22:08 +0100, Jan Kratochvil wrote:
> jankratochvil/devmem

The name, the subject and some of the comments talks about /dev.
But I assume this is really about /proc?

> An security breach countercase upstream is ftruncate(2) for mmap(2)ed and
> close(2)ed file which was not possible without map_files/ before.  This is why
> map_files/ was restricted to CAP_SYS_ADMIN (=root) in the end:
> 	http://article.gmane.org/gmane.linux.file-systems/57619
> 	http://article.gmane.org/gmane.linux.file-systems/57640
> 
> As their concern there is about R/W mapping and modifications of the file they
> also claim it is only an example, that the security implications may be wider.
> 
> My original plan was to make the mapping accessible for non-root in R/O mode
> as elfutils is enough with R/O access only.
> 
> But now I think about a countercase where one has only a part of file
> mmap(2)ped while the file is unlinked or located in inaccessible directory.
> Then R/O map_files/ access will make the whole file accessible to the user.
> This makes even R/O map_files/ non-root access losening of security rules.

Yeah, that makes sense. It is a pity there isn't some way to restrict
access to the map files as if accessed by the process itself did it. So
only allow opening if the file is actually directly accessible or if the
process already has a fd open to the file anyway.

But if we have a way to get the same results without needing the
map_files at all that is of course even better.

> Fortunately for backtracing of deleted executables/libraries one does not need
> to access any unmapped memory (assuming here Fedora executables built with
> -fasynchronous-unwind-tables).  ELF header, program headers and PT_GNU_EH_FRAME
> are all mapped in memory and accessible by PTRACE_PEEKTEXT (and /proc/PID/mem).
> 
> Therefore the whole solution can be done in elfutils emulating all mapped
> parts of ELF from remote memory.  Moreover elfutils already provides support
> for ELFs in the middle of a file - as elfutils supports .a archives.
> 
> (1)
> This patchset (/dev/PID/mem solution) works only on recent Linux kernels
> (tested kernel-3.13.3-201.fc20.x86_64) as older kernels (RHEL-6) required
> PTRACE_ATTACHed PID to read its /dev/PID/mem.  This patch does not try to
> workaround older kernels by doing PTRACE_ATTACH.

I had something somewhat working using ptrace attach and the
elf_from_remote_memory that we are already using for getting access to
the vdso. But I had trouble with the alignment requirements not always
working and there was the issue of how to pass through the pid of the
process from the report callback to the find_elf callback. I'll see if I
can make that work using your approach and then we can maybe use that as
fallback when direct access doesn't work on older kernels.

> (2)
> The former patch using /proc/PID/map_files/ still may be useful so that
> elfutils can access .debug_frame or .symtab embedded in the same file
> (=not using /usr/lib/debug separate debuginfo).
> /proc/PID/exe also makes sense.
> 
> /proc/PID/map_files/ - all files            but only for root tracers
> /proc/PID/exe        - only main executable but even for non-root tracers

Yes, that was the problem with the elf_from_remote_memory approach too,
you only get access to the phdrs mapped in segments, so no easy lookup
for anything not loaded or needing shdr/name lookups.

> (3)
> There is currently a bug in symbol resolving (eu-stack without -q) of deleted
> prelinked executables.
> 
> This is because this libdwfl/dwfl_module_getdwarf.c comment is no longer true
> after this patch
>          If there are no section headers at all (full stripping), then
>          the end of the first segment is a valid synchronization address.
>          This cannot happen in a prelinked file, since prelink itself
>          relies on section headers for prelinking and for undoing it.
>          (If you do full stripping on a prelinked file, then you get what
>          you deserve--you can neither undo the prelinking, nor expect to
>          line it up with a debug file separated before prelinking.)
> 
> because /proc/PID/mem does not have to have section headers mapped.
> 
> Primarily I am not aware how to fix it.

I also don't immediately know how. But nice find. This seems somewhat
obscure. It means, the main ELF file is deleted, but you do still have
the separate debuginfo file around, which we find (based on build-id)
and then cannot properly match/sync because the main, now deleted, file
was prelinked. I think in general the main file and the separate
debuginfo file will both be deleted. It is a slightly confusing corner
case though.

Cheers,

Mark



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]