Re: don't run elfutils as root in ABRT

[Adam Šulc <sulcadam12 at gmail dot com>]

Hi Mark,

Avast signature turned off thanks for notice :)

On Tue, May 9, 2017 at 2:40 PM, Mark Wielaard <mark@klomp.org> wrote:
> Hi Adam,
>
> 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
> advertisement.)
>
> On Tue, 2017-05-09 at 10:49 +0200, Adam Šulc wrote:
>> On Mon, May 8, 2017 at 2:10 PM, Mark Wielaard <mark@klomp.org> 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).
>

Yes this works but if set-uid program crashes (e.g. passwd) this does not work.
I mean when ABRT core backtrace runs under root and then dropping
the privileges because of security reason, it drops to the fsuid in
case of SetUID
program, that crashed, otherwise drops to the uid of the crashed program.
You can read more there if you are interested:
https://github.com/xsulca00/abrt/blob/iss%23890/src/hooks/abrt-hook-ccpp.c#L730

>> >> 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.

Thank you. Now I see. One more question.
Do both ways (read file from file system & read the ELF image from the process)
produce equivalent result like reading from file system gives the same output
as reading ELF image from process?

Thanks,
Adam