Re: blocking weird file names (was: xterm terminal crash due to malicious character sequences in file name)

[Ali Polatel <alip () hexsys org>]

On Tuesday, 19 August 2025 at 04:46, Jacob Bachmeyer <jcb62281 () gmail com> wrote:

> On 8/17/25 20:44, David A. Wheeler wrote:

> > [...]

> > I proposed forbidding such characters to POSIX. They *did* add a few mechanisms to POSIX
> > to make it somewhat easier to handle filenames with control characters
> > (e.g., find -print0 and xargs -0). However, although they do not *require*
> > that operating systems allow these filenames, they are not forbidden either.

> My understanding is that POSIX allows almost any syscall to return EPERM.

> > I have a draft Linux Security Module (LSM) that lets you determine
> > what kind of filenames are allowed to be created. By default it would require
> > non-control-chars, no leading '-', no trailing ' ', and UTF-8 encoding,
> > but it would let you configure further. I intend to go back to that
> > to finish it off & propose it. My original proposal merely prevented creation;
> > it would be possible to hide them entirely, but that comes with its own issues.

> If you do that, please make absolutely certain that any processes running from files that would be hidden (and 
> therefore blocked from exec(2)) are killed when the policy becomes effective. I once (years ago) cleaned out a 
> backdoor that was named 'syslogd ' (with the trailing space). (Clever, except that the real syslogd does not open a 
> raw socket and *does* open the log files...)

> Also, if you want to block trailing whitespace, please do not forget the various *other* Unicode space characters and 
> their UTF-8 forms.

> Could you allow those files to appear in directory listings (including stat(2)) but open(2)/exec(2)/etc. would return 
> EPERM? I suggest that unlink(2) should be unrestricted, and perhaps also open(..., O_WRONLY) (to allow such files to 
> be shredded if the admin desires).

> Would a per-process category be feasible? This would allow an admin to "unlock" any such files found for a limited 
> subset of processes (presumably the admin's shell) to facilitate forensic collection and/or secure deletion.

You may also consider the syd sandbox for an unprivileged, per-process solution
which has filename limitations since version 3.17.4, see:
https://man.exherbo.org/syd.7.html#Enhanced_Path_Integrity_Measures

I noticed syd's implementation, which is largely based on Safename LSM of Mr. Wheeler (huge thanks!),
does not include any checks for Unicode space characters. I'll look into improving that.
Thank you very much for the idea!

> Does this need to be an entirely new module or could it be an extension to SELinux?

>

>

> -- Jacob

>


Best,
alip

Attachment: publickey - alip@hexsys.org - 0xC22DA9DE.asc
Description:

Attachment: signature.asc
Description: OpenPGP digital signature