This is a tracking bug for Change: Enable systemd service hardening features for default system services For more details, see: https://fedoraproject.org/wiki/Changes/SystemdSecurityHardening Improve security by enabling some of the high level systemd security hardening settings that isolate and sandbox default system services. If you encounter a bug related to this Change, please do not comment here. Instead create a new bug and set it to block this bug.
Hi Rahul, As we are passed the Testable deadline for F40 Changes and approaching the 100% complete deadline, I am doing a routine check in on all change tracker bugs to make sure changes are on track or not to land successfully in F40. Have you any updates to share on the progress of this change? Thanks! Aoife
Only a single PR has been merged so far https://src.fedoraproject.org/rpms/abrt/pull-request/32 Unfortunately, even the PRs filed a long time back have stalled out with no feedback or response in a long time after the initial responses. Couple of examples: https://src.fedoraproject.org/rpms/dbus-broker/pull-request/11 https://src.fedoraproject.org/rpms/httpd/pull-request/40 I am working my way through the rest but unless we can expedite some of these, we will have to postpone the feature
As I wrote in https://discussion.fedoraproject.org/t/f40-change-proposal-systemd-security-hardening-system-wide/96423/4, and as it has been requested for abrt & dbus-broker already, I would recommend that you start upstream with those changes to get better traction. This will make maintaining those hardening settings much easier for everyone. The test suites for applications / the CI are also usually run upstream, not in Fedora so that's where issues will be caught.
I am happy to work wherever it makes sense but there are wide variations in maintainer, upstream preferences as well as even test suite availability. httpd for example, the service file is shipped within the package and not upstream and there is apparently a Red Hat internal test suite so I will have to wait for that. In other cases, I have started opening PRs upstream as well. Thanks for the feedback.
FEDORA-2024-b9d5622cc4 (realmd-0.17.1-11.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-b9d5622cc4
I am maintaining a sheet to keep track of this now fyi https://docs.google.com/spreadsheets/d/1BLKqBSsF0B9gYz6b4TIPnJ93SpiUVDiD8z_80pTyXJc/edit#gid=0
The current status, according to the spreadsheet, is 3 merged PRs, and a bunch PRs open. Should we mark this as postponed to F41?
Yep. That would be my recommendation. There are some merged upstream but they aren't going to land in Fedora at this stage.
Hi Rahul, Is this change on track to be completed before the Beta freeze deadline of Tuesday August 27th? I see a number of the PRs are stalled on upstream decisions. Do you want to continue for F41 or retarget for F42? Or withdraw the change completely? Thanks, Aoife
Retargeting this change to F42 as no progress has been made.
Hi Rahul, how goes this change for F42? The testable deadline is coming up in about two weeks, on Feb 4th, and changes need to be in good shape at this point https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_change_process_milestones Please let me know if you need to defer this to F43, otherwise if youre good to go for the change to be ready to meet the testable requirements, please update the status of the tracker bug to MODIFIED. Thanks! Aoife
We discussed this during the FESCo meeting today: AGREED: Change is dropped because of inactivity. Owner is welcome to resubmit if the work is picked up again. (+5, 0, 0) @amoloney, please reassign.