[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f6K0A_kST8iSTV9cEJTcRN9oJcT2JeOo4rQUZEzWIfeTp1hdOgs5XR0ZRhpdXHwrVzcbbup6mfvyOZ2rwQiciWRAoC7Hx0Iy1HCiP1CekLw=@hexsys.org>
Date: Tue, 19 Aug 2025 12:05:40 +0000
From: Ali Polatel <alip@...sys.org>
To: oss-security@...ts.openwall.com
Cc: "David A. Wheeler" <dwheeler@...eeler.com>, Vincent Lefevre <vincent@...c17.net>
Subject: Re: blocking weird file names (was: xterm terminal crash due to malicious character sequences in file name)
On Tuesday, 19 August 2025 at 04:46, Jacob Bachmeyer <jcb62281@...il.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
Download attachment "publickey - alip@...sys.org - 0xC22DA9DE.asc" of type "application/pgp-keys" (637 bytes)
Download attachment "signature.asc" of type "application/pgp-signature" (344 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
