Hello, On Wednesday, August 14, 2024 1:44:17 PM EDT pgnd wrote: > > Not really here to defend the current setting. But I have run with it set > > to 1 for several years and have not noticed any real issues. > > understood. > > and that's been my _personal_ experience as well. it's been necessary for a > few bits-n-bobs, and hasn't broken anything that *I* am aware of. > > that said, the issue remains that > > -- it was widely 'discussed', the dropped &/or forgotten about (?) > -- the default (Fedora & RH, at least) IS =0, and the config *does* have > that "stuff will break"-ism. -- the "password manager" company (1password > in this particular case), _requires_ the setting to _not_ break some of > their app's 'secure' functionality > > when asked about the 'contradiction' with current RH/Fedora defaults and > docs, they replied the other day to a user I wouldn't frame it as a contradiction. When I was doing the threat analysis for RHEL common criteria, one factor that is different than a desktop is that servers are largely unattended. They may have agents keeping an eye on things, but we can only certify what's in the distribution. So, I chose to do more of a lockdown. In some cases we change the default setting. In other cases we just add some code to the scap security guides. This one change should not be done on its own, but as an overall hardening strategy. So, not only was this sysctl changed, but a number of others too. Anaconda/kickstart has the ability to pull in the the SCAP security policy and perform the hardening at install. This is the path we chose. Somewhere along the way, these setting for common criteria found their way into the DISA STIG. They added extra text that tries to convince you that it's the right thing. For common criteria, it was to protect against someone getting access to ephemeral keys through ptracing a process of the same use. (This is an actual requirement.) Normal ptrace permissions prevent users ptracing each other. But this was in the context of a server that is up all the time and largely unattended. So, I'd position this more as a case where this was solved by SCAP content rather than changing a bunch of defaults and having that discussion. That said, this one change hasn't really caused any problems I know of. And with the DISA STIG asking for it on millions of systems, it's pretty well tested. > "After speaking with the team I've collected some more information on the > current situation with |ptrace_scope| being set to 1. While the Fedora man > page is technically correct, setting |ptrace| to anything other than 0 > "will break programs". A more realistic take of the system would be that > "it has the chance to break some program functionality". > > Applications that depend on the ability to perform arbitrary |ptraces| for > functionality other than debugging are uncommon and it is a better > practice to temporarily disable |ptrace_scope| rather than allow the > setting to always be available. > > This warning applies to a few edge cases and is unlikely to impact your > system usage. However, the command |sudo sysctl -w > kernel.yama.ptrace_scope=1| is a temporary variable that is reset upon > restarting your device." > > Ignoring the fuzzy hand-waving and lack of a clear statement, it leaves > deployments to RH/Fedora + 1password users in a pickle -- which vendor's > guidance do you believe/trust? What *I* control, *I* can change. But it's > an uphill push to say "Ignore Redhat" or "Ignore 1password" to others. Changing one setting isn't a lockdown. But if you're wondering about the nature of the apparent difference, it's really just one is a strategy to mitigate a comprehensive threat model vs defaults settings that are easily changeable. -Steve > It'd be much cleaner if RH/Fedora & 1password hashed it out, and came to > some reasonable outcome, or at least clear guidance / documentation. > > Particularly as Ubuntu/Debian already appear (?) to have made the switch to > =1. -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
