Bug 1472341 - Information leak in systemd-coredump
Summary: Information leak in systemd-coredump
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-18 13:42 UTC by wegge
Modified: 2017-07-18 14:29 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-18 14:29:16 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description wegge 2017-07-18 13:42:00 UTC
coredumpctl info leaks information about call stacks for processes owned by other users: 

Running coredumpctl 1545 as a normal user, gives me more details about a UID 0 process, than I'd be comfortable sharing with others:


           PID: 1545 (packagekitd)
           UID: 0 (root)
           GID: 0 (root)
        Signal: 11 (SEGV)
     Timestamp: Mon 2017-07-17 21:41:38 CEST (16h ago)
  Command Line: /usr/libexec/packagekitd
    Executable: /usr/libexec/packagekitd
 Control Group: /system.slice/packagekit.service
          Unit: packagekit.service
         Slice: system.slice
       Boot ID: ee51450b59b144f7a4dacb19ab8a73c8
    Machine ID: de6ac91575e44f3d89b6d41c2ce371ba
      Hostname: localhost.localdomain
       Storage: /var/lib/systemd/coredump/core.packagekitd.0.ee51450b59b144f7a4d
       Message: Process 1545 (packagekitd) of user 0 dumped core.
                
                Stack trace of thread 9417:
                #0  0x00007f0c3734679e _int_malloc (libc.so.6)
                #1  0x00007f0c37347b00 _int_realloc (libc.so.6)
                #2  0x00007f0c3734a7bb realloc (libc.so.6)
                ...

Comment 1 Zbigniew Jędrzejewski-Szmek 2017-07-18 13:49:36 UTC
coredumpctl is just an unprivileged frontend, it cannot leak anything.

But it's true that that any user who has access to system logs has access to coredump information about services. That's a known shortcoming, because there are only two levels of access to system logs: none (default), and full (everybody in adm, wheel). That's a limitation of the architecture of systemd-journald.

It *would* be nice to make access more granular, but that would require changing how journald files are stored.

Comment 2 wegge 2017-07-18 14:03:50 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #1)
> coredumpctl is just an unprivileged frontend, it cannot leak anything.
> 
> But it's true that that any user who has access to system logs has access to
> coredump information about services. That's a known shortcoming, because
> there are only two levels of access to system logs: none (default), and full
> (everybody in adm, wheel). That's a limitation of the architecture of
> systemd-journald.
> 
> It *would* be nice to make access more granular, but that would require
> changing how journald files are stored.

One thing is knowing that a coredump have taken place. Another thing is getting the full backtrace of the dumped process. The public user have no legitimate need for that information.

Comment 3 Zbigniew Jędrzejewski-Szmek 2017-07-18 14:08:15 UTC
The public user has no access to that. Only users which have been added to one of the administrative groups.

Comment 4 wegge 2017-07-18 14:28:33 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #3)
> The public user has no access to that. Only users which have been added to
> one of the administrative groups.

OK, there I was caught unaware. However, there's a lack of consistency :)

[awj@localhost tmp] $ coredumpctl gdb 1545 

...

                #5  0x000055add002e5aa _start (packagekitd)

File "/var/lib/systemd/coredump/core.packagekitd.0.ee51450b59b144f7a4dacb19ab8a73c8.1545.1500320498000000.lz4" is not readable: Permission denied


Note You need to log in before you can comment on or make changes to this bug.