Re: [PATCH] PR28204, debuginfod IMA

[Frank Ch. Eigler]

Hi -


Thanks for the review.

> [...]
> BTW. The diff doesn't show the newly added binary files. So the patch
> cannot be applied. Please use git send-email or git format-patch for
> that.

I would not expect the emailed patch to apply, esp. with all the other
work done in the intermediate months, which is why the code is also in
the git branch.  The binary files do not seem effectively reviewable
anyway.


> > debuginfod: PR28204 - RPM IMA per-file signature verification
> > 
> > Recent versions of Fedora/RHEL include per-file cryptographic
> > signatures in RPMs, not just an overall RPM signature.  This work
> > extends debuginfod client & server to extract, transfer, and verify
> > those signatures.  These allow clients to assure users that the
> > downloaded files have not been corrupted since their original
> > packaging.  Downloads that fail the test are rejected.
> 
> It is not just corruption, since it is a cryptographic signature, it
> is also a proof that the files are what the distro actually packaged
> and distributes.

Yes, that seems another way of saying the same thing.


> [...]
> > The default is ima:permissive mode, which allows signatures to
> > function like a checksum to detect accidental corruption, but accepts
> > operation in a mix of signed and unsigned packages & servers.
> 
> I still think "permissive" is confusing. Since it is a term also used
> by e.g. selinux, but doesn't work that way. And it doesn't seem
> connected with the threat-model that enforcing protects against.

The connection is the following:
"enforcing" mode protects against accidental or deliberate (MITM) corruption.
"permissive" mode protects against accidental corruption.

> Since it is a different concept maybe it shouldn't be part of this
> patch. It is a form of integrity checking, but doesn't protect (or
> warns) about integrity failures. 

It does protect and warn against integrity failures of the form of 
incorrect signatures.

> As pointed out in another bug (#30978) if you want to do checking
> for (accidental) corruption of files you can also use the
> .gnu_debuglink CRC.
>
> Or maybe add this is a followup to this patch, adding an ima:checking
> and crc:checking marker (or maybe a generic checking marker that might
> do both)?

A .gnu_debuglink checksum that is part of the executable can to some
extent protect the debuginfo that it is a checksum of, but cannot
protect the executable, or the source files.


> > NB: debuginfod section queries are excluded from signature
> > verification at this time, and function as though ima:ignore were in
> > effect.
> 
> imho this is odd. You either enforce the data produced by the server
> is certified, or it isn't. I understand that doing that for the
> section data is difficult because you effectively have to download and
> check the whole file. But it feels wrong to claim to enforce the
> signatures and then not do it.

Yes, it is odd.  Unfortunately, it is not possible to enforce crypto
signatures from distros upon unsigned slices.  A couple of possible
solutions:

- accept it as is with documentation

- disable section queries from enforcing-mode servers (which could
  then nuke gdbindex capability for e.g. future fedora/gdb users)

- have debuginfod servers operate their own crypto signing engine,
  sign sections and everything, distribute keys somehow (DNS?
  distributed with elfutils?), let clients fetch & trust those
  certificates; however does note prove distro provenance 


> > IMA signatures are verified against a set of signing certificates.
> > These are normally published by distributions.  A selection of such
> > certificates is included with the debuginfod client, but some system
> > directories are also searched.  See $DEBUGINFOD_IMA_CERT_PATH.  These
> > certificates are assumed trusted.
> 
> Including default system directories seems fine. But I don't think
> elfutils should ship certificates itself. That is the job of the
> distro or user.

The user or the distro the user is running may not be the same one
that the binaries the user is debugging comes from.  By shipping
Fedora/RHEL/CentOS certificates, we allow a Ubuntu person to debug a
RHEL container, and trust debuginfod content for it.

> We aren't in a position to make sure the certificates are valid
> and/or can be trusted.

Why not?  We can document where we got them - I believe they are all
public somewhere or other already.

> If we ship certificates we also need some mechanism to invalidate
> them if they get compromised.

We can "git rm" them from our repo, and the next elfutils update would
make them go away.

> [...]
> > +AM_CONDITIONAL([ENABLE_IMA_VERIFICATION],[test "$enable_ima_verification" 
> > = "xrpmimaevmcrypto"])
> 
> So currently it is enabled if you have the right libraries installed,
> otherwise it is disabled. It might be nice if it can be explicitly
> enabled/disabled. And make configure fa

Re: [PATCH] PR28204, debuginfod IMA

[Mark Wielaard]

Hi,

Continued review...

On Thu, 2023-09-07 at 08:55 -0400, Frank Ch. Eigler via Elfutils-devel
wrote:
> diff --git a/debuginfod/debuginfod.cxx b/debuginfod/debuginfod.cxx
> index d72d2ad16960..8c3298586672 100644
> --- a/debuginfod/debuginfod.cxx
> +++ b/debuginfod/debuginfod.cxx
> @@ -113,6 +113,13 @@ using namespace std;
>  #define MHD_RESULT int
>  #endif
>  
> +#ifdef ENABLE_IMA_VERIFICATION
> +  #include 
> +  #include 
> +  #include 
> +  #include 
> +#endif
> +
>  #include 
>  #include 
>  #include 

OK.

> @@ -431,6 +438,8 @@ static const struct argp_option options[] =
> { "disable-source-scan", ARGP_KEY_DISABLE_SOURCE_SCAN, NULL, 0, "Do not 
> scan dwarf source info.", 0 },
>  #define ARGP_SCAN_CHECKPOINT 0x100A
> { "scan-checkpoint", ARGP_SCAN_CHECKPOINT, "NUM", 0, "Number of files 
> scanned before a WAL checkpoint.", 0 },
> +#define ARGP_KEY_KOJI_SIGCACHE 0x100B
> +   { "koji-sigcache", ARGP_KEY_KOJI_SIGCACHE, NULL, 0, "Do a koji specific 
> mapping of rpm paths to get IMA signatures.", 0 },
> { NULL, 0, NULL, 0, NULL, 0 },
>};

OK. Is actually documented below. But first couldn't find it because of
the escaped '-' (good), which apparently is a real issue:
https://lwn.net/SubscriberLink/947941/b427a4409847108d/

> @@ -486,6 +495,7 @@ static bool scan_source_info = true;
>  static string tmpdir;
>  static bool passive_p = false;
>  static long scan_checkpoint = 256;
> +static bool requires_koji_sigcache_mapping = false;
>  
>  static void set_metric(const string& key, double value);
>  // static void inc_metric(const string& key);
> @@ -692,6 +702,9 @@ parse_opt (int key, char *arg,
>if (scan_checkpoint < 0)
>  argp_failure(state, 1, EINVAL, "scan checkpoint");
>break;
> +case ARGP_KEY_KOJI_SIGCACHE:
> +  requires_koji_sigcache_mapping = true;
> +  break;
>// case 'h': argp_state_help (state, stderr, 
> ARGP_HELP_LONG|ARGP_HELP_EXIT_OK);
>  default: return ARGP_ERR_UNKNOWN;
>  }

OK. Maybe produce a warning/error ifndef ENABLE_IMA_VERIFICATION ?

> @@ -1933,6 +1946,131 @@ handle_buildid_r_match (bool internal_req_p,
>return 0;
>  }
>  
> +  // Extract the IMA per-file signature (if it exists)
> +  string ima_sig = "";
> +  #ifdef ENABLE_IMA_VERIFICATION
> +  do
> +  {
> +FD_t rpm_fd;
> +if(!(rpm_fd = Fopen(b_source0.c_str(), "r.ufdio")))
> +{
> +  if (verbose) obatched(clog) << "There was an error while opening " << 
> b_source0 << endl;
> +  break; // Exit IMA extraction
> +}

So Fopen is part of rpm devel? Is there documentation?
Specifically what "r.ufdio" means?

> +Header rpm_hdr;
> +if(RPMRC_FAIL == rpmReadPackageFile(NULL, rpm_fd, b_source0.c_str(), 
> &rpm_hdr))
> +{
> +  if (verbose) obatched(clog) << "There was an error while reading the 
> header of " << b_source0 << endl;
> +  Fclose(rpm_fd);
> +  break; // Exit IMA extraction
> +}

OK.

> +// Fill sig_tag_data with an alloc'd copy of the array of IMA signatures 
> (if they exist)
> +struct rpmtd_s sig_tag_data;
> +rpmtdReset(&sig_tag_data);
> +do{ /* A do-while so we can break out of the koji sigcache checking on 
> failure */
> +if(requires_koji_sigcache_mapping)
> +{
> +  /* NB: Koji builds result in a directory structure like the following
> +  - PACKAGE/VERSION/RELEASE
> +- ARCH1
> +  - foo.rpm   // The rpm known by debuginfod
> +- ...
> +- ARCHN
> +- data
> +  - signed// Periodically purged (and not scanned by 
> debuginfod)
> +  - sigcache
> +- ARCH1
> +  - foo.rpm.sig   // An empty rpm header
> +- ...
> +- ARCHN
> +- PACKAGE_KEYID1
> +  - ARCH1
> +- foo.rpm.sig   // The header of the signed rpm. This is the 
> file we need to extract the IMA signatures
> +  - ...
> +  - ARCHN
> +- ...
> +- PACKAGE_KEYIDN
> +  We therefore need to do a mapping of P/V/R/A/N-V-R.A.rpm -> 
> P/V/R/data/sigcache/KEYID/A/N-V-R.A.rpm.sig. There are 2 key insights here
> +  1. We need to go 2 directories down from sigcache to get to the rpm 
> header. So to distinguish ARCH1/foo.rpm.sig and 
> PACKAGE_KEYID1/ARCH1/foo.rpm.sig
> +  we can look 2 directories down
> +  2. Its safe to assume that the user will have all of the required 
> verification certs. So we can pick from any of the PACKAGE_KEYIDi directories.
> +  For simplicity we choose first we match against
> +  See: https://pagure.io/koji/issue/3670
> +  */

Nice comment, thanks for the bug reference.
Note tiny typo "PACKAGE_KEYIDi" (extra 'i').

> +  // Do the mapping from b_source0 to the koji path for the signed rpm 
> header
> +  string signed_rpm_path = b_source0;
> +  size_t insert_pos = string::npos;
> +  for(int i = 0; i < 2; i++) insert_pos = signed_rpm_path.rfin

[PATCH] Fixed formatting of man page and --help options and added additional test case to ensure the correct source file is output.

[Housam Alamour]

Hello,
Here are the requested changes.
---
 doc/Makefile.am|  2 +-
 doc/srcfiles.1 | 58 ++
 src/srcfiles.cxx   | 29 ++-
 tests/run-srcfiles-self.sh |  6 
 4 files changed, 55 insertions(+), 40 deletions(-)

diff --git a/doc/Makefile.am b/doc/Makefile.am
index db5a842e..87de4f0b 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -17,7 +17,7 @@
 ## You should have received a copy of the GNU General Public License
 ## along with this program.  If not, see .
 EXTRA_DIST = COPYING-GFDL README
-dist_man1_MANS=readelf.1 elfclassify.1
+dist_man1_MANS=readelf.1 elfclassify.1 srcfiles.1
 notrans_dist_man3_MANS=elf_update.3 elf_getdata.3 elf_clone.3 elf_begin.3
 notrans_dist_man7_MANS=
 notrans_dist_man8_MANS=
diff --git a/doc/srcfiles.1 b/doc/srcfiles.1
index 245c2d27..da7c6989 100644
--- a/doc/srcfiles.1
+++ b/doc/srcfiles.1
@@ -18,55 +18,63 @@
 ..
 
 .SH "NAME"
-eu-srcfiles \- Lists the source files of a dwarf/elf file.
+eu-srcfiles \- Lists the source files of a DWARF/ELF file.
 
 .SH "SYNOPSIS"
 eu-srcfiles [\fB\-0\fR|\fB\-\-null\fR] [\fB\-c\fR|\fB\-\-cu\-only\fR] 
[\fB\-v\fR|\fB\-\-verbose\fR] INPUT
 
 .SH "DESCRIPTION"
-\fBeu-srcfiles\fR lists the source files of a given \s-1dwarf/elf\s0
-file.  This list is based on a search of the dwarf debuginfo, which
+\fBeu-srcfiles\fR lists the source files of a given \s-DWARF/ELF\s0
+file.  This list is based on a search of the DWARF debuginfo, which
 may be automatically fetched by debuginfod if applicable.  The target
 file may be an executable, a coredump, a process, or even the running
 kernel.  The default is the file 'a.out'.  The source file names are
 made unique and printed to standard output.
  
-.SH "OPTIONS"
+.SH "INPUT OPTIONS"
 The long and short forms of options, shown here as alternatives, are
 equivalent.
+.TP
+\fB--core=COREFILE\fR
+Find addresses from signatures found in COREFILE.
+
+.TP
+\fB--debuginfo-path=PATH\fR
+Search path for separate debuginfo files.
 
-.SS "Input Options"
+.TP
+\fB-e FILE\fR, \fB--executable=FILE\fR
+Find addresses in FILE.
 
-Only one INPUT option may be used.  The default is '-e a.out'.
+.TP
+\fB-k\fR, \fB--kernel\fR
+Find addresses in the running kernel.
+
+.TP
+\fB-K\fR, \fB--offline-kernel[=RELEASE]\fR
+Kernel with all modules.
 
 .TP
-\fB\-e FILE\fR, \fB\-\-executable=FILE\fR
-Find source files for FILE.
+\fB-M FILE\fR, \fB--linux-process-map=FILE\fR
+Find addresses in files mapped as read from FILE in Linux /proc/PID/maps 
format.
 
 .TP
-\fB\-\-core=COREFILE\fR
-Find source files for the executable plus all shared libraries loaded
-into the coredumped process.
+\fB-p PID\fR, \fB--pid=PID\fR
+Find addresses in files mapped into process PID.
 
 .TP
-\fB\-p PID\fR, \fB\-\-pid=PID\fR
-Find source files for the executable plus all shared libraries loaded
-into running process PID.
+\fB-?\fR, \fB--help\fR
+Give this help list.
 
 .TP
-\fB\-M FILE\fR, \fB\-\-linux\-process\-map=FILE\fR
-Find source files for the executable plus all shared libraries loaded
-into a process, with given map file in linux /proc/PID/maps format.
-The file names listed in the map file must exist and be current on the
-system.
+\fB--usage\fR
+Give a short usage message.
 
 .TP
-\fB\-K, \-\-offline\-kernel[=RELEASE]
-Find source files for the kernel plus all installed modules
-with the given RELEASE version.  This may be very slow if
-dwarf is found via debuginfod.
+\fB-V\fR, \fB--version\fR
+Print program version.
 
-.SS "Output Options"
+.SH "OUTPUT OPTIONS"
 
 .TP
 \fB\-0, \-\-null\fR
@@ -78,7 +86,7 @@ Only list the CU names.
 
 .TP
 \fB\-v, \-\-verbose\fR
-Increase verbosity of logging messages to stderr.
+Increase verbosity of logging messages.
 
 
 .SH EXAMPLES
diff --git a/src/srcfiles.cxx b/src/srcfiles.cxx
index c948269d..a4cc91a1 100644
--- a/src/srcfiles.cxx
+++ b/src/srcfiles.cxx
@@ -41,8 +41,9 @@ ARGP_PROGRAM_BUG_ADDRESS_DEF = PACKAGE_BUGREPORT;
 /* Definitions of arguments for argp functions.  */
 static const struct argp_option options[] = 
 {
+  { NULL, 0, NULL, OPTION_DOC, N_("Output options:"), 1 },
   { "null", '0', NULL, 0,
-N_ ("items are separated by a null, not whitespace."), 0 },
+N_ ("Separate items by a null instead of a newline."), 0 },
   { "verbose", 'v', NULL, 0,
 N_ ("Increase verbosity of logging messages."), 0 },
   { "cu-only", 'c', NULL, 0, N_ ("Only list the CU names."), 0 },
@@ -50,10 +51,10 @@ static const struct argp_option options[] =
 };
 
 /* Short description of program.  */
-static const char doc[] = N_("Show source files of given ELF FILE.");
+static const char doc[] = N_("Lists the source files of a DWARF/ELF file. The 
default input is the file 'a.out'.");
 
 /* Strings for arguments in help texts.  */
-static const char args_doc[] = N_("[FILE]");
+static const char args_doc[] = N_("INPUT");
 
 /* Prototype for option handler.  */
 static error_t parse_opt (int key, char *a

Re: [PATCH] Fixed formatting of man page and --help options and added additional test case to ensure the correct source file is output.

[Aaron Merey]

On Tue, Oct 24, 2023 at 1:35 PM Housam Alamour  wrote:
>
> Hello,
> Here are the requested changes.

Thanks Housam. I made a couple tweaks to the testcases, squashed this
patch into "PR 3: debuginfod-find should have a source-list verb"
and merged it into the main branch.

Aaron

[Bug debuginfod/30000] introduce new srcfiles tool

[amerey at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=3

Aaron Merey  changed:

   What|Removed |Added

 CC||amerey at redhat dot com
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #2 from Aaron Merey  ---
srcfiles tool has been added in the following commit

commit cb4f0e0fffbcdb124bd1b82f558095a9c7aa64b1
Author: Housam Alamour 
Date:   Thu Sep 7 14:29:19 2023 -0400

PR 3: debuginfod-find should have a source-list verb

* seclines.cxx: Introduce new tool  that compiles a list of source
files associated with a specified dwarf/elf file. This
compilation relies on searching the dwarf debug information,
which can be automatically retrieved via debuginfod using
libdwfl functions when required. The target file can
encompass various types, such as an executable, a coredump,
a running process, or the currently executing kernel. The
source file names are rendered as unique entries and then
displayed on the standard output.

*  run-srcfiles-self.sh: New test-case for tool.

https://sourceware.org/bugzilla/show_bug.cgi?id=3

Signed-off-by: Housam Alamour 

-- 
You are receiving this mail because:
You are on the CC list for the bug.

☠ Buildbot (Sourceware): elfutils - failed test (failure) (master)

[builder]

A new failure has been detected on builder elfutils-gentoo-sparc while building 
elfutils.

Full details are available at:
https://builder.sourceware.org/buildbot/#builders/225/builds/112

Build state: failed test (failure)
Revision: cb4f0e0fffbcdb124bd1b82f558095a9c7aa64b1
Worker: gentoo-sparc
Build Reason: (unknown)
Blamelist: Housam Alamour 

Steps:

- 0: worker_preparation ( success )

- 1: set package name ( success )

- 2: git checkout ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/225/builds/112/steps/2/logs/stdio

- 3: autoreconf ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/225/builds/112/steps/3/logs/stdio

- 4: configure ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/225/builds/112/steps/4/logs/stdio
- config.log: 
https://builder.sourceware.org/buildbot/#builders/225/builds/112/steps/4/logs/config_log

- 5: get version ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/225/builds/112/steps/5/logs/stdio
- property changes: 
https://builder.sourceware.org/buildbot/#builders/225/builds/112/steps/5/logs/property_changes

- 6: make ( warnings )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/225/builds/112/steps/6/logs/stdio
- warnings (3): 
https://builder.sourceware.org/buildbot/#builders/225/builds/112/steps/6/logs/warnings__3_

- 7: make check ( failure )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/225/builds/112/steps/7/logs/stdio
- test-suite.log: 
https://builder.sourceware.org/buildbot/#builders/225/builds/112/steps/7/logs/test-suite_log

- 8: prep ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/225/builds/112/steps/8/logs/stdio

- 9: build bunsen.cpio.gz ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/225/builds/112/steps/9/logs/stdio

- 10: fetch bunsen.cpio.gz ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/225/builds/112/steps/10/logs/stdio

- 11: unpack bunsen.cpio.gz ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/225/builds/112/steps/11/logs/stdio

- 12: pass .bunsen.source.gitname ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/225/builds/112/steps/12/logs/stdio

- 13: pass .bunsen.source.gitdescribe ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/225/builds/112/steps/13/logs/stdio

- 14: pass .bunsen.source.gitbranch ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/225/builds/112/steps/14/logs/stdio

- 15: pass .bunsen.source.gitrepo ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/225/builds/112/steps/15/logs/stdio

- 16: upload to bunsen ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/225/builds/112/steps/16/logs/stdio

- 17: clean up ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/225/builds/112/steps/17/logs/stdio

- 18: make distclean ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/225/builds/112/steps/18/logs/stdio

Re: [PATCH] PR28204, debuginfod IMA

[Mark Wielaard]

Hi Frank,

On Tue, Oct 24, 2023 at 09:27:43AM -0400, Frank Ch. Eigler wrote:
> > BTW. The diff doesn't show the newly added binary files. So the patch
> > cannot be applied. Please use git send-email or git format-patch for
> > that.
> 
> I would not expect the emailed patch to apply, esp. with all the other
> work done in the intermediate months, which is why the code is also in
> the git branch.  The binary files do not seem effectively reviewable
> anyway.

It would be really convenient though. And modern git format-patch does
includes base tree information which allows tools to stich commits at
the right place. It would also help with patchwork and pre-commit CI.
https://git-scm.com/docs/git-format-patch#_base_tree_information

> > [...]
> > > The default is ima:permissive mode, which allows signatures to
> > > function like a checksum to detect accidental corruption, but accepts
> > > operation in a mix of signed and unsigned packages & servers.
> > 
> > I still think "permissive" is confusing. Since it is a term also used
> > by e.g. selinux, but doesn't work that way. And it doesn't seem
> > connected with the threat-model that enforcing protects against.
> 
> The connection is the following:
> "enforcing" mode protects against accidental or deliberate (MITM) corruption.
> "permissive" mode protects against accidental corruption.
> 
> > Since it is a different concept maybe it shouldn't be part of this
> > patch. It is a form of integrity checking, but doesn't protect (or
> > warns) about integrity failures. 
> 
> It does protect and warn against integrity failures of the form of 
> incorrect signatures.

My issue is that I don't really understand "permissive". Originally I
assumed it was like selinux permissive mode, it does do the checks,
but if they fail we just warn and continue. That seems a clear concept.

So instead permissive is more like a optional checksum. And the
checksum we are using is really a signature. So we do more than
checksumming, we also check the certificate (is it still valid,
expired, etc.) It is just imho a very "sloppy" concept. I don't
understand the permissive threat-model. And I don't really understand
the name "permissive". Which makes it hard to know if we have
implemented it correctly. e.g. if there is a signature, but we don't
have the corresponding certificate to check it against, should it
still fail, or is it more like a none-signed file and we can be
"permissive" and accept it? Maybe I don't have enough imagination.

On the other hand I think the enforcing mode is pretty clear. It
provides the user with those files that the distro provider really
meant to ship. It makes sure that the tools relying on debuginfod only
process known-good/trusted files.

> > As pointed out in another bug (#30978) if you want to do checking
> > for (accidental) corruption of files you can also use the
> > .gnu_debuglink CRC.
> >
> > Or maybe add this is a followup to this patch, adding an ima:checking
> > and crc:checking marker (or maybe a generic checking marker that might
> > do both)?
> 
> A .gnu_debuglink checksum that is part of the executable can to some
> extent protect the debuginfo that it is a checksum of, but cannot
> protect the executable, or the source files.

Yeah, you are right, it wouldn't work for the executables, and for the
debug files it only works if you already have the executable on disk
(and trust them). In theory a debugfile can contain MD5 sums in the
DWARF line tables which could be used to check the source files (there
is also the time and size of the file). But in practice those aren't
added (at least not by gcc).

This probably shows how I am confused by the permissive/checking
concept.

> > > NB: debuginfod section queries are excluded from signature
> > > verification at this time, and function as though ima:ignore were in
> > > effect.
> > 
> > imho this is odd. You either enforce the data produced by the server
> > is certified, or it isn't. I understand that doing that for the
> > section data is difficult because you effectively have to download and
> > check the whole file. But it feels wrong to claim to enforce the
> > signatures and then not do it.
> 
> Yes, it is odd.  Unfortunately, it is not possible to enforce crypto
> signatures from distros upon unsigned slices.  A couple of possible
> solutions:
> 
> - accept it as is with documentation
> 
> - disable section queries from enforcing-mode servers (which could
>   then nuke gdbindex capability for e.g. future fedora/gdb users)
> 
> - have debuginfod servers operate their own crypto signing engine,
>   sign sections and everything, distribute keys somehow (DNS?
>   distributed with elfutils?), let clients fetch & trust those
>   certificates; however does note prove distro provenance 

I think only option 2 makes sense given the enforcing threat-model.

Optionally we could do the section part locally, download the whole
file, check the ima signature, then provide the

[Bug libdw/30980] offline.c:53: dwfl_offline_section_address: Assertion `mod->e_type == ET_REL' failed.

[sam at gentoo dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30980

Sam James  changed:

   What|Removed |Added

 CC||sam at gentoo dot org
   See Also||https://github.com/systemd/
   ||systemd/issues/29585

-- 
You are receiving this mail because:
You are on the CC list for the bug.