Hide Forgot
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
Oh, and the contents of the file are also available over d-bus from systemd anyway.
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.
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?
Yes, I read it. I'll levy some requirements on systemd to fix this hole. Thanks.
(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
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 ).
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.
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.
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.
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.
"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
*** Bug 1171372 has been marked as a duplicate of this bug. ***
Steve, any chance of fixing this? Could you please respond to arguments above? Thanks.
*** Bug 1192231 has been marked as a duplicate of this bug. ***
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.
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.
Oh sorry, I haven't seen that it is already in rawhide.
Fixed in audit-2.5.
Thanks.