[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a6370d77-36a6-4b26-85a8-4fc8d2354cf3@gmail.com>
Date: Mon, 18 Aug 2025 21:24:07 -0500
From: Jacob Bachmeyer <jcb62281@...il.com>
To: oss-security@...ts.openwall.com, "David A. Wheeler"
<dwheeler@...eeler.com>
Cc: Vincent Lefevre <vincent@...c17.net>
Subject: Re: blocking weird file names (was: xterm terminal
crash due to malicious character sequences in file name)
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.
Does this need to be an entirely new module or could it be an extension
to SELinux?
-- Jacob
Content of type "text/html" skipped
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.
