On Sat, Aug 29, 2020 at 7:30 PM Mikhail Novosyolov <m.novosyolov@xxxxxxxxxxxx> wrote: > > 29.08.2020 19:42, Casey Schaufler пишет: > > On 8/29/2020 4:08 AM, Mikhail Novosyolov wrote: > >> Hello everyone, > >> > >> We have been thinking on such problem: read access to a file may be restricted with SELinux MCS/MLS, especially MLS/MCS. > >> If a file with restricted access is inside a directory without restricted access, its name is readable. > >> Name of the file may be used to store some "secret" information. > >> Some system directories, e.g. /var/tmp, are writable for multiple users, and they may use it to exchange secret information, > >> bypassing restrictions. > >> > >> Is there a way to restrict access to names of such files? > > TL;DR - No > > > > This is probably the oldest active question in the history > > of UNIX/Linux security. In the late 1980's it arose many times > > in the process of system security evaluations. Because the > > name of a file is data in the directory, and not an attribute > > of the file in UNIX/Linux filesystems, access to it is controlled > > by access to the directory. > > > > There was initially much crying and gnashing of teeth about this > > in the evaluation community. Especially with regard to /tmp. > > SELinux (and Smack, and B&L systems from the old days) have > > explicit policies controlling how files can be created in > > directories such that you can read the directory but not the > > file attributes. While this can't prevent creating a file named > > launch-the-missiles-at-noon, it provides accountability. > Very interesting, thanks.But are there technical restrictions to implement hiding names of files? > Let's assume that we will be OK with performance penalty of directory listing because of checking access rights to each file inside the directory. > Were there any attempts to implement this? We did it in DTOS, a predecessor to Flask which was a predecessor to SELinux. It had a per-file visible permission that controlled visibility of the file name. However, you then had various complications, e.g. what if a process at another level tries to create a file with the same name (create a new file with that name magically extended with a label suffix that is hidden from userspace? deny it thereby giving away its existence?), and there were still ways of detecting the presence of hidden subdirectories/files (e.g. checking the link count on the directory, checking the size of the directory, looking for gaps in the offsets returned by getdents()). I also seem to recall someone proposing a LSM hook for filtering directories but didn't see it on a quick glance at the linux-security-module archives on lore (but those are unfortunately limited to the last few years).
