From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72423 invoked by alias); 9 May 2017 12:40:11 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 72396 invoked by uid 89); 9 May 2017 12:40:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=U*mark, advertisement, avast, services X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 09 May 2017 12:40:09 +0000 Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 5C11130132F5; Tue, 9 May 2017 14:40:10 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 4F4924000704; Tue, 9 May 2017 14:40:10 +0200 (CEST) Message-ID: <1494333610.14615.26.camel@klomp.org> Subject: Re: don't run elfutils as root in ABRT From: Mark Wielaard To: Adam =?UTF-8?Q?=C5=A0ulc?= Cc: elfutils-devel@sourceware.org, mhabrnal@redhat.com, msuchy@redhat.com Date: Tue, 09 May 2017 16:05:00 -0000 In-Reply-To: References: <1494245406.14443.14.camel@klomp.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.12.11 (3.12.11-22.el7) Mime-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2017-q2/txt/msg00207.txt.bz2 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 =C5=A0ulc wrote: > On Mon, May 8, 2017 at 2:10 PM, Mark Wielaard wrote: > > On Fri, 2017-05-05 at 18:25 +0200, Adam =C5=A0ulc 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_b= acktrace. > > > > If you just drop privileges to the user owning the process you should > > keep having access. >=20 > 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#L= 246 > >> 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? >=20 > 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