Hiding names of unreadable files

Hiding names of unreadable files

[Mikhail Novosyolov]

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?

What may theoretically be done:

1. Hide such files from directory listing. A bad idea, because most pieces of software (and people)
are not ready to deal with situations when a file does not exist but a file with such name cannot be
created because it already exists.

2. Change name of the file to "????". Even worse.

3. Do not show the name of the file at all. I do not know how it should be done,
something like showing that an "inode" exists.

4. Try to just restrict write access to directories without proper MLS labels:
separate /tmp for arch user, maybe separate /var/tmp for each user, chmod -x (maybe via ACL) for /run etc.

Can and should it be done with SELinux? What about other LSM modules?
Is there a more generic approach to hide names of unreadable files?

Re: Hiding names of unreadable files

[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.

>
> What may theoretically be done:
>
> 1. Hide such files from directory listing. A bad idea, because most pieces of software (and people)
> are not ready to deal with situations when a file does not exist but a file with such name cannot be
> created because it already exists.
>
> 2. Change name of the file to "????". Even worse.
>
> 3. Do not show the name of the file at all. I do not know how it should be done,
> something like showing that an "inode" exists.
>
> 4. Try to just restrict write access to directories without proper MLS labels:
> separate /tmp for arch user, maybe separate /var/tmp for each user, chmod -x (maybe via ACL) for /run etc.
>
> Can and should it be done with SELinux? What about other LSM modules?
> Is there a more generic approach to hide names of unreadable files?
>

Re: Hiding names of unreadable files

[Topi Miettinen]

On 29.8.2020 14.08, 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?
> 
> What may theoretically be done:
> 
> 1. Hide such files from directory listing. A bad idea, because most pieces of software (and people)
> are not ready to deal with situations when a file does not exist but a file with such name cannot be
> created because it already exists.
> 
> 2. Change name of the file to "????". Even worse.
> 
> 3. Do not show the name of the file at all. I do not know how it should be done,
> something like showing that an "inode" exists.
> 
> 4. Try to just restrict write access to directories without proper MLS labels:
> separate /tmp for arch user, maybe separate /var/tmp for each user, chmod -x (maybe via ACL) for /run etc.
> 
> Can and should it be done with SELinux? What about other LSM modules?
> Is there a more generic approach to hide names of unreadable files?
> 

PAM module pam_namespace sets up private directories in /tmp etc. and 
pam_tmpdir is probably similar.

-Topi

Re: Hiding names of unreadable files

[Mikhail Novosyolov]

30.08.2020 00:26, Topi Miettinen пишет:
> On 29.8.2020 14.08, Mikhail Novosyolov wrote:
>>
>> 4. Try to just restrict write access to directories without proper MLS labels:
>> separate /tmp for arch user, maybe separate /var/tmp for each user, chmod -x (maybe via ACL) for /run etc.
>
> PAM module pam_namespace sets up private directories in /tmp etc. and pam_tmpdir is probably similar.

Yes. But it causes problems in different places, by far not all software is ready to have different files in /tmp from different users.

In general this does work. But for /tmp. What about /var/tmp, /run? In theory a similar polyinstantiation can be done for them, but new problems will be encountered.

/var/tmp is even more interesting because it is normally not a tmpfs, some software can store permanent data there, e.g. KDE4 stores cache files there. Per-user onion-mounting (overlayfs, aufs) or a simple `mount --bind` could be used there.

Re: Hiding names of unreadable files

[Mikhail Novosyolov]

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?

Re: Hiding names of unreadable files

[Casey Schaufler]

On 8/29/2020 4:30 PM, Mikhail Novosyolov 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?

Yes, it has been attempted and isn't really that hard if you're willing to
abandon the name/inode pair model for directory entries. That leads to breaking
the traditional filesystem semantics, some of which are "curious" but important.
Hard links need to either be carefully coordinated or unsupported if attributes
are stored in the directory entry, for example. This worked in the days when
a system supported a single filesystem type, but would be much more challenging
with VFS.

Re: Hiding names of unreadable files

[Stephen Smalley]

On Sat, Aug 29, 2020 at 7:30 PM Mikhail Novosyolov
<m.novosyolov@rosalinux.ru> 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).