Bug 1472341
| Summary: | Information leak in systemd-coredump | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | wegge |
| Component: | systemd | Assignee: | systemd-maint |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | johannbg, lnykryn, msekleta, muadda, ssahani, s, systemd-maint, zbyszek |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-07-18 14:29:16 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. (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. The public user has no access to that. Only users which have been added to one of the administrative groups. (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 |
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) ...