don't run elfutils as root in ABRT

don't run elfutils as root in ABRT

[Adam Šulc]

Hello,

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.
First, we open these files under root,
then we drop capabilities & privileges and finally, we generate core_backtrace.

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?

Thank you

Re: don't run elfutils as root in ABRT

[Frank Ch. Eigler]

Hi -

On Fri, May 05, 2017 at 06:25:30PM +0200, Adam Å ulc wrote:

> [...]
> 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?

Via file name "/dev/fd/232" ?

- FChE

Re: don't run elfutils as root in ABRT

[Mark Wielaard]

Hi Adam,

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.

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

Cheers,

Mark

Re: don't run elfutils as root in ABRT

[Mark Wielaard]

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

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

Cheers,

Mark

Re: don't run elfutils as root in ABRT

[Adam Šulc]

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

Re: don't run elfutils as root in ABRT

[Mark Wielaard]

Hi Adam,

On Tue, 2017-03-07 at 13:39 +0100, 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.
> First, we open these files under root,
> then we drop capabilities & privileges and finally, we generate
> core_backtrace.

If you drop priviliges to the uid of the process then you should still
be able to open /proc files for that process/user. That seems the
simplest solution.

> We have one problem, that we need to pass the opened /proc file to this
> function:
> dwfl_linux_proc_report (Dwfl *dwfl, pid_t pid)
> Because this function opens the /proc file itself, thus it is hard coded
> and we cannot pass our /proc file pointer:
> https://github.com/abrt/satyr/blob/master/lib/core_unwind_elfutils.c#L251
> 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?

See the function right after dwfl_linux_proc_report in libdwfl.h:

/* Call dwfl_report_module for each file mapped into the address space of PID.
   Returns zero on success, -1 if dwfl_report_module failed,
   or an errno code if opening the proc files failed.  */
extern int dwfl_linux_proc_report (Dwfl *dwfl, pid_t pid);

/* Similar, but reads an input stream in the format of Linux /proc/PID/maps
   files giving module layout, not the file for a live process.  */
extern int dwfl_linux_proc_maps_report (Dwfl *dwfl, FILE *);

It does slightly less because it doesn't know the running process pid,
but might do enough for your use case. But I think just dropping
privileges to the uid of the process is easier.

Cheers,

Mark