This is the mail archive of the
mailing list for the elfutils project.
Re: don't run elfutils as root in ABRT
- From: Mark Wielaard <mark at klomp dot org>
- To: Adam Šulc <sulcadam12 at gmail dot com>
- Cc: elfutils-devel at sourceware dot org, mhabrnal at redhat dot com, msuchy at redhat dot com
- Date: Tue, 09 May 2017 14:40:10 +0200
- Subject: Re: don't run elfutils as root in ABRT
- Authentication-results: sourceware.org; auth=none
- References: <CAJdWHfiBdLV3p-c0PydsSkx-rNMmznDdpP7S1giwDPq-STx1bA@mail.gmail.com> <firstname.lastname@example.org> <CAJdWHfgTf4p7_nUq6R3n2wJVCjUG123BmQBUA-f6GguN-P3gLQ@mail.gmail.com>
Please don't include HTML mail. The mailinglist will not accept it.
(In this case it is your HTML avast signature that looks like an
On Tue, 2017-05-09 at 10:49 +0200, Adam Šulc wrote:
> On Mon, May 8, 2017 at 2:10 PM, Mark Wielaard <email@example.com> wrote:
> > On Fri, 2017-05-05 at 18:25 +0200, Adam Šulc wrote:
> >> I work on ABRT improvement in order to increase security related to
> >> core backtrace generating using elfutils library.
> >> Here is a short description of my problem:
> >> Goal is to not call base code in elfutils and gdb functions under root.
> >> If you are more interested you can read more there:
> >> https://github.com/abrt/abrt/issues/890
> >> We need root for opening /proc files only.
> > And, depending on system settings, for ptrace attach or other
> > interprocess services like reading memory with process_vm_read.
> >> First, we open these files under root,
> >> then we drop capabilities & privileges and finally, we generate core_backtrace.
> > If you just drop privileges to the user owning the process you should
> > keep having access.
> I have tried in ABRT dropping privileges & access these special files.
> It doesn't work in my case.
What exactly do you do when "dropping privileges"? If you drop
privileges to the uid that runs the process you really should have
access (unless something weird like yama is involved).
> >> We have one problem that still persists, we need to pass the opened
> >> /proc/[tid]/mem file to this function:
> >> dwfl_linux_proc_find_elf
> >> Because this function opens the /proc/[tid]/mem file itself, thus it
> >> is hard coded and we cannot pass our /proc/[tid]/mem file pointer:
> >> https://github.com/abrt/satyr/blob/master/lib/core_unwind_elfutils.c#L246
> >> So we dont know how to pass the opened file to this function.
> >> Do you have any idea how to pass the open file descriptor into the
> >> function? Or what is the best way how to achieve this?
> > You cannot easily unless you write your own Dwfl_Callbacks.find_elf
> > handler. But as long as you only drop privileges to the user owning the
> > process you should be able to open that file.
> > Note that this code path should only be called if the ELF module
> > couldn't be found on the file system. In that case it will try to slurp
> > it from the process memory. Does that fallback path not work as intended
> > for your setup?
> Could you please explain what do you mean by "ELF module couldn't be
> found on the file system" ? I would like to try that if ABRT can
> process that or not.
See the code in libdwfl/linux-proc-maps.c (dwfl_linux_proc_find_elf). If
the module name starts with a '/' and it is a regular file then it will
first try to just read that file from the file system. Only if it fails
to open the file through the module path will the code try to read the
ELF image from the process itself.