On Tuesday, 19 August 2025 at 04:46, Jacob Bachmeyer <[email protected]> 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
publickey - [email protected] - 0xC22DA9DE.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
