RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1311543 - restrictive permissions on auditd.service
Summary: restrictive permissions on auditd.service
Keywords:
Status: CLOSED DUPLICATE of bug 1291464
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: audit
Version: 7.2
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Steve Grubb
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-24 12:39 UTC by Mario Trangoni
Modified: 2016-02-24 14:02 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 959483
Environment:
Last Closed: 2016-02-24 14:02:23 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Mario Trangoni 2016-02-24 12:39:07 UTC
+++ This bug was initially created as a clone of Bug #959483 +++

Description of problem:
/usr/lib/systemd/system/auditd.service is -rw-r-----. This is annoying and breaks systemd running in test mode as non-root. No additional security is provided whatsoever: the file is distributed through in a package,
and if the admin wants to modify the file, they are supposed to copy the file and put it in /etc/systemd/system/. Should the admin desire to restrict permissions, she can do it then.

Version-Release number of selected component (if applicable):
audit-2.2.3-2.fc19.x86_64

--- Additional comment from Zbigniew Jędrzejewski-Szmek on 2013-05-03 11:27:21 EDT ---

Oh, and the contents of the file are also available over d-bus from systemd anyway.

--- Additional comment from Steve Grubb on 2013-05-09 12:53:18 EDT ---

Not likely to fix this. I keep this package in sync with RHEL's and we have to keep all file permissions related to auditing root readable only.

--- Additional comment from Zbigniew Jędrzejewski-Szmek on 2013-05-09 13:53:18 EDT ---

Right... But did you read my arguments how the contents of this file can be accessed in at least two different ways by unprivileged users and why the restriction for this file is thus completely useless?

--- Additional comment from Steve Grubb on 2013-05-09 14:05:55 EDT ---

Yes, I read it. I'll levy some requirements on systemd to fix this hole. Thanks.

--- Additional comment from Zbigniew Jędrzejewski-Szmek on 2013-05-09 15:03:30 EDT ---

(In reply to comment #4)
> Yes, I read it. I'll levy some requirements on systemd to fix this hole.
> Thanks.
Don't forget to file one against yum and the Fedora package distribution system. If you want to restrict access to a packaged file, even audit.srpm cannot be visible to (non-root?) users.

I'll answer the part about systemd and "this hole":
systemd unit files are designed to be very simple, and are not intended to be modified by users. Recent systemd versions even have a whole system of .d directories which can carry modifications to units without modifying packaged unit files [1]. In fact, unit files are supposed to be shared across distributions. In light of this, packaged unit files are always world-readable.

Unrestricted access to current state over dbus is great to allow various monitoring and overview tools to work. *Much* of this runtime information is also available through /proc/ and /sys/fs/cgroup/systemd hierarchies anyway, but dbus api makes it easy to query.

[1] http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Description

--- Additional comment from Michael Scherer on 2013-08-29 16:41:23 EDT ---

yes, in the case of free software, the requirement is overkill and a bit useless. One could argue that someone could recompile the package, but that's not the case, I think the only reason is to minimize risk for being rejected on certification. 

And on the RHEL side, due to some certifications ( stuff like EAL4+ or similar, I do not know which one but I trust Steve to not do that for pleasure ), stuff related to audit must be readable only from root. 

The maintener want to keep 1 spec for RHEL and Fedora, and while i prefer 2 set of spec, this is within his right. 

And I think the goal is to avoid someone who will interpret the spec in a different fashion to block the certification, because this is costly and lengthy.
Sure, a spec that is not precise enough to be interpreted clearly is not ideal, but I doubt that we can change it now ( and that's not the only one ).

--- Additional comment from Tomasz Torcz on 2014-03-10 08:49:49 EDT ---

Current systemd started to complain about those pointless permissions:

systemd[1]: Configuration file /usr/lib/systemd/system/auditd.service is marked world-inaccessible. This has no effect as configuration data is
accessible via APIs without restrictions. Proceeding anyway.

--- Additional comment from Lennart Poettering on 2014-03-10 16:58:09 EDT ---

I specifically added this warning to systemd in Rawhide now to make sure packages like audit get fixed: we will warn about all unit files with non-sensical access permissions like auditd uses them.

The contents of the auditd unit files is available in the upstream open source repo anyway, and also via "systemctl show", hence there is exactly zero point in trying to play games here.

Auditd and its tools could actually be useful software. Unfortunately though it is just obnoxious by playing pointless games with permission bits.

--- Additional comment from Georg Sauthoff on 2014-12-04 06:38:40 EST ---

The warning is still present with Fedora 21:

systemd[1]: Configuration file /usr/lib/systemd/system/auditd.service is marked world-inaccessible. This has no effect as configuration data is accessible via APIs without restrictions. Proceeding anyway.

--- Additional comment from Fedora End Of Life on 2015-01-09 13:02:01 EST ---

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

--- Additional comment from Zbigniew Jędrzejewski-Szmek on 2015-01-09 13:07:26 EST ---

"Inside of /usr, files should be owned by root:root unless a more specific user or group is needed for security. They must be universally readable".

https://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions

--- Additional comment from Kamil Páral on 2015-04-04 04:03:17 EDT ---



--- Additional comment from Kamil Páral on 2015-04-04 04:05:20 EDT ---

Steve, any chance of fixing this? Could you please respond to arguments above? Thanks.

--- Additional comment from Branko Grubić (bitlord) on 2015-07-05 06:28:36 EDT ---



--- Additional comment from Fedora End Of Life on 2015-11-04 05:42:45 EST ---

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

--- Additional comment from Edgar Hoch on 2015-11-04 06:01:22 EST ---

The problem still exists in Fedora 22. Please update the Fedora version of this bug report.

And please fix it, it can be done in a few minutes.

--- Additional comment from Edgar Hoch on 2015-11-04 06:02:23 EST ---

Oh sorry, I haven't seen that it is already in rawhide.

--- Additional comment from Steve Grubb on 2016-01-11 15:30:14 EST ---

Fixed in audit-2.5.

--- Additional comment from Zbigniew Jędrzejewski-Szmek on 2016-01-12 07:53:42 EST ---

Thanks.

Comment 2 Steve Grubb 2016-02-24 14:02:23 UTC
Marking as duplicate. Please use existing bugs when possible,

*** This bug has been marked as a duplicate of bug 1291464 ***


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