Local root vulnerability in snap-confine [LWN.net]

Local root vulnerability in snap-confine

Posted Feb 18, 2022 18:33 UTC (Fri) by mpr22 (subscriber, #60784)
In reply to: Local root vulnerability in snap-confine by epa
Parent article: Local root vulnerability in snap-confine

It's "sacred" because getting any traction for moving away from such permissiveness means an unknown amount of work for an unknown number of people who don't even know you're planning to impose that work on them.

to post comments

Local root vulnerability in snap-confine

Posted Feb 18, 2022 21:11 UTC (Fri) by ms-tg (subscriber, #89231) [Link] (1 responses)

> It's "sacred" because getting any traction for moving away from such permissiveness means an unknown amount of work for an unknown number of people who don't even know you're planning to impose that work on them.

I wonder if there are steps that, over some years, could help make the unknown number of people visible? For example, what if Linux, either in the file systems or more likely in distro-level utilities, simply detected filenames that violated certain rules, and let the user know that these existed and might need to be renamed to follow a proposed RFC naming convention in the future if it becomes accepted?

Perhaps users could opt-in to also reporting counts back to a central server?

I'm even picturing a nice web page, the way big security vulnerabilities have these days? Maybe 'linux-filenames-rfc.io'? Which could include the latest text of the proposal, links to Github where changes can be proposed, mailing lists where it is discussed, etc?

Using these sorts of community consensus approaches, might it be possible to get more of a defined sense of how often how big a real-world impact would be felt by any proposed reduction in Linux filename permissiveness?

Local root vulnerability in snap-confine

Posted Feb 24, 2022 11:07 UTC (Thu) by Wol (subscriber, #4433) [Link]

What you need is something that OPTIONALLY enforces all this stuff. Like David Wheeler's comments on filenames for example - a *create*time flag for a filesystem that says "enforce these safety rules".

Sure, all hell could then break loose, as old apps assume they can write garbage, etc etc, but it gives *developers* the opportunity to have a flag day and clean up their own stuff. Then they recommend that users enable this flag, which can't be enabled on existing systems to avoid breaking them, and all this goodness is enforced going forwards.

Then you reverse the default state of the flag so all of a sudden, people with old apps have to ask for the old behaviour ... But the breakage is minimised by making it easy for those in the know to be early adopters and test their own systems. You only need something like SUSE's Open Build System flipping their default setting, as developer's build systems start breaking and a distro could then rapidly switch their own default knowing all the apps they've built are compliant ...

Cheers,
Wol