Bug 1655145 - RFE: optionally sanitize journalctl output before public release
Summary: RFE: optionally sanitize journalctl output before public release
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-30 18:11 UTC by Steve
Modified: 2018-12-01 16:35 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-30 19:50:10 UTC


Attachments (Terms of Use)

Description Steve 2018-11-30 18:11:11 UTC
Description of problem:
Journalctl output is sometimes requested for analyzing bugs, but the output may contain sensitive information, such as host names, user names, MAC addresses, IP addresses, etc.

This is a proposal to offer an option to "sanitize" journalctl output according to various criteria.

Version-Release number of selected component (if applicable):
systemd-238-10.git438ac26.fc28.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. $ journalctl -b
2. Search for host names, user names, MAC addresses, IP addresses, etc.

Actual results:
Sensitive information is scattered throughout the output.

Expected results:
Sensitive information is optionally "obfuscated", resulting in "sanitized" output.

Additional info:

The "abrt" and "selinux" reporting tools can already "sanitize" bug reports before posting.

Comment 1 Steve 2018-11-30 18:12:48 UTC
Add RFE, Security keywords.

Comment 2 Zbigniew Jędrzejewski-Szmek 2018-11-30 19:50:10 UTC
Please open a bug upstream or start a thread on systemd-devel@freedesktop.org. I doubt that this can be meaningfully done, but even if it can, it's not a downstream Fedora thing.

Comment 3 Steve 2018-11-30 22:20:04 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #2)
> ...  I doubt that this can be meaningfully done, ...

My proposal would be to add support for tagging log entries as "sensitive" and leave the decision as to what should be tagged up to the developers of programs doing the logging.

With such tags, users could run something like this:

$ journalctl --no-sensitive --no-hostname -b

That would filter out records or fields that have been tagged as "sensitive".

Comment 4 Zbigniew Jędrzejewski-Szmek 2018-12-01 08:31:34 UTC
There's already a general mechanism to add arbitrary metadata to log entries.
For example this could be done by either sticking SENSITIVE=_all into the metadata of the record, or adding SENSITIVE=MESSAGE,LOGIN,... (the names of some other fields in the log message which the application considers sensitive). The problem is not in defining a mechanism like that, but in convincing authors of various daemons to make use of it. If you think this is useful, convince e.g. authors or maintainers of sshd to implement this on the source side.

Comment 5 Steve 2018-12-01 16:35:34 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #4)
> ... a general mechanism to add arbitrary metadata to log entries. ...

Thanks for pointing that out.

> ... convincing authors of various daemons to make use of it. ...

OK. The kernel is one of the "offenders":

Bug 1647159 - UDF does not respect console log level when DVD is mounted


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