Local root vulnerability in snap-confine

Posted Feb 18, 2022 16:20 UTC (Fri) by epa (subscriber, #39769)
In reply to: Local root vulnerability in snap-confine by intgr
Parent article: Local root vulnerability in snap-confine

I think you can also blame whoever decided that ( ) and space should be legal characters in a mount point path name. It serves no purpose to allow them. But this is a cultural hot button issue, since the original Unix decision to allow any byte except / and NUL in a filename has become somehow sacred. (I'm not even talking about filenames in general, just the name of mount points!)

You can also blame whoever came up with the mountinfo format, but that may be a little unfair as I'm sure it has simply evolved rather than being designed. With hindsight, if you are pasting together strings in a formatted text output you should think in advance of what to do if one of the formatting characters (like, I don't know, newline) appears in a string. But again, there's no cultural consensus on what to do, and any scheme you invented would probably be parsed wrongly by lots of userland code, since it's an uncommon case.

Local root vulnerability in snap-confine

Posted Feb 18, 2022 18:33 UTC (Fri) by mpr22 (subscriber, #60784) [Link] (2 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.

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

Local root vulnerability in snap-confine

Posted Feb 19, 2022 9:40 UTC (Sat) by adobriyan (subscriber, #30858) [Link]

The technical bug is that (deleted) is appended, not prepended so it is impossible to disambiguate just by looking at the output.

Local root vulnerability in snap-confine

Posted Feb 19, 2022 10:26 UTC (Sat) by intgr (subscriber, #39733) [Link]

> whoever came up with the mountinfo format, but that may be a little unfair as I'm sure it has simply evolved rather than being designed

I don't really blame whoever came up with it, but I blame kernel developers for not offering better alternatives for new use cases and migrating old kludges over.

Kernel developers should decide on a new unambiguous and extensible serialization format for complex nested data structures. In 1990s these lessons hadn't really been learned yet, but in 2022 we have protobuf, Avro, Arrow, ASN.1, JSON and plenty more. I'm sure we can find at least one that suits the kernel use case.

> blame whoever decided that ( ) and space should be legal characters in a mount point path name

This wouldn't even help that much. Restricting characters in path names would solve this particular issue for paths, but there are still plenty of other strings with arbitrary content that may end up being communicated to user space. So would you propose blocking a set of characters in *all* kernel inputs?

I feel like a broken record at this point, but again: if you're having trouble transmitting certain characters in your serialization format, it's the serialization format that sucks.

Local root vulnerability in snap-confine

Posted Feb 20, 2022 3:03 UTC (Sun) by foom (subscriber, #14868) [Link] (6 responses)

Eh? No use for spaces and parentheses? Both of those are incredibly useful in filenames for humans! Characters like newlines or tabs, sure -- those have no place in filenames. And you could arguably exclude double quotes as well, but a filename like "Aaron's Report: Cats (2010)" is completely reasonable.

If there's blame to be had, it'd be for the Unix shell language which treats strings in a variable unsafely by default!

Local root vulnerability in snap-confine

Posted Feb 21, 2022 7:01 UTC (Mon) by epa (subscriber, #39769) [Link] (5 responses)

I meant mount points should be restricted to alphanumeric and -_. characters. For filenames in general I agree that humans expect to use ().

On some platforms space is not a legal character in filenames but you can use non-breaking space, which isn’t treated specially by the shell. I’m not sure whether that is better or worse.

Local root vulnerability in snap-confine

Posted Feb 21, 2022 12:43 UTC (Mon) by zdzichu (subscriber, #17118) [Link] (4 responses)

Even "-" character should not be allowed as the first character of a filename. There are many gotchas with various characters. David A. Wheeler summarized them neatly in https://dwheeler.com/essays/fixing-unix-linux-filenames.html .

Local root vulnerability in snap-confine

Posted Feb 21, 2022 13:37 UTC (Mon) by adobriyan (subscriber, #30858) [Link] (3 responses)

> Even "-" character should not be allowed as the first character of a filename.

'-' is allowed in URLs. Any site issuing randomised names (like: YT) to user submitted content will create a file starting with minus easily.

Local root vulnerability in snap-confine

Posted Feb 21, 2022 14:15 UTC (Mon) by zdzichu (subscriber, #17118) [Link] (2 responses)

Everything except NULL and / is allowed in filenames. But it doesn't mean it's a good idea to use it. Please take time to read the essay, it is eye-opening.

And you do not need a website. Just touch -- --foot-shooter (or touch -- -rf\ . if you like).

Local root vulnerability in snap-confine

Posted Feb 21, 2022 17:33 UTC (Mon) by adobriyan (subscriber, #30858) [Link] (1 responses)

David Wheeler's proposal would ban every ~1/(26+26+10+4) = 1/66-th video downloaded by youtube-dl. It is too late to ban anything.

GNU ls(1) started to quote filenames with spaces at some point, it was huge step in right direction because copy paste suddenly started working "out of the box". More features lke this are necessary.

Local root vulnerability in snap-confine

Posted Feb 21, 2022 18:04 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

> David Wheeler's proposal would ban every ~1/(26+26+10+4) = 1/66-th video downloaded by youtube-dl. It is too late to ban anything.

Just add automatic escaping for such names.