How secure is it to use secret directory names to share files on unix?

Question

There is an old trick on unix systems to allow a non-root user to "securely" share files with particular other users.

mkdir share
chmod 711 share #others can traverse share, but can't list its contents
mkdir share/d2ef7c19-5d7e-446f-ab97-d7d6c3dc8a8c #(randomly chosen secret subdir name)
cp -R /path/to/stuff_to_share share/d2ef7c19-5d7e-446f-ab97-d7d6c3dc8a8c
chmod -R 755 share/d2ef7c19-5d7e-446f-ab97-d7d6c3dc8a8c #allow others who know the secret path to access shared files

EDIT (clarification): I have to tell the people I want to share files with the secret path (in this case, ~myid/share/d2ef7c19-5d7e-446f-ab97-d7d6c3dc8a8c) in order to share the files with them.

My question is: how secure is this? If a third party (non-root) does not know the secret share name (in the example above: d2ef7c19-5d7e-446f-ab97-d7d6c3dc8a8c), is there any way they can learn about it?

You didnt shared it, it's a misconception you have, you simply hidded it. Shared would mean with samba/ftp in example — yagmoth555, Jul 07 '16 at 18:36
You accepted an answer that requires root access to work. That is a rather uninteresting solution as there is no protection from root at all — Neil Smithline, Jul 07 '16 at 20:57
@NeilSmithline if you tested my program you'll find that assertion to be false. — Matthew Ife, Jul 07 '16 at 21:01
in short: it's not the absolute worst thing ever, but there are better ways of doing it. — dandavis, Jul 07 '16 at 22:54

score 1 · Answer 1 · answered Jul 07 '16 at 18:35

1

This is called "Security by Obscurity", and is not a reliable form of hiding files at all. There are plenty of tools that can search a whole filesystem and index the files within, regardless of what permissions you're assigning to some randomly named folder.

You have conflated an adversary not knowing something with them being unable to learn it. In your example, you aren't actually doing anything to stop someone who obtains the folder name from listing and reading the contents. Once the name stops being secret, the jig is up. This is unlike a password, as passwords are stored in a one-way hash, whereas folder names are in clear text on the filesystem.

An analogy: You have a house, with a door, and you want to keep people from just walking through your door. You can move the door to some hard to find spot on the house that isn't visible by just walking around the outside. But there's nothing stopping someone from pressing on various parts of your house to find the door.

Or, you can put the door in an obvious location, but prevent anyone from just opening it, with a lock.

answered Jul 07 '16 at 18:35

zymhan

141
6

4

This is not security by obscurity any more than a password is. There are flaws with this scheme, but that it's security by obscurity is not one of them. – David Schwartz Jul 07 '16 at 18:41
@DavidSchwartz you'll have to elaborate then. OP is proposing "hiding" the files by putting them in a randomly named folder that they assume can't be found by the wrong person. That seems to me the definition of security by obscurity. – zymhan Jul 07 '16 at 19:03
@WildVelociraptor Assuming the parent directory is correctly locked down to prevent a directory listing, the secret name of the directory has identical function to a password. i.e. "you aren't actually doing anything to stop someone who knows the *password* from listing and reading the contents" is a silly objection to passwords, for obvious reasons. – ceejayoz Jul 07 '16 at 19:06
@ceejayoz That doesn't prevent someone from obtaining the name of the folder somehow, or any other number of ways to find out that there are files within it. Passwords are stored with one-way hashes, so you can't just find it in cleartext in a file. This folder name is in no way actually secret, it is simply hidden (i.e. obscured). – zymhan Jul 07 '16 at 19:10
if something is hidden, and nobody (else) is allowed to look for it, how is it not a secret? – dandavis Jul 07 '16 at 20:31
@dandavis If you assume an unsophisticated and undetermined adversary, then yes just picking a random name and changing the folder permissions would suffice. However, as should be clear to anyone, we have more sophisticated methods of hiding information on a computer for a reason. – zymhan Jul 07 '16 at 20:36
not untrue, but we have file permissions for a reason as well ;) – dandavis Jul 07 '16 at 20:38
Also true. I am just uncomfortable starting from the assumption that your account on a multi-user server which you don't own can keep users from knowing that your files are there. Especially if you didn't setup the server, you really don't know what kind of information is leaking out to other users via logs, processes, monitoring, or other means. – zymhan Jul 07 '16 at 20:57
3

There is a presumption of secrecy for passwords that does not exist for file paths. For example, care is taken to ensure that passwords aren't logged or put in scripts. No such care is generally taken for filenames. Even if users are told to protect filenames, there's no guarantee that every tool and system they interact with will take equal precautions. As such, not all "secrets" are equal. Passwords are better secrets than filenames. – Neil Smithline Jul 07 '16 at 21:08

Matthew Ife · Accepted Answer · 2016-07-07T21:04:21.750

0

Well, you said any means.

Its not efficient, but one means to do this would be to continuously scan all running processes on a system (in particular if you expect someone to access a file in a few moments) and inspect all their arguments for matching paths to the base directory of the share. Once a match is found, you print the result.

The hope here is the accessor is using a command that takes the path to the file as an argument.

EDIT: This works for me for somewhat longer running processes like vim, dd or catting a large file.

#!/usr/bin/python
import glob, re

share = re.compile('.*myshare.*')

while True:
  procs = glob.glob('/proc/*/cmdline')
  for p in procs:
    try:
      with open(p) as cmdline:
        cmd = cmdline.read()
        if share.search(cmd):
          print cmd.replace('\0', ' ')
    except OSError:
      pass

It doesn't pick up quick like 'touch' in its current form. You could potentially increase your chances by forking many processes doing the same search and/or overloading CPU resources to increase the running length of target processes -- although on Linux due to the scheduler and autogrouping thats still somewhat difficult.

This program doesn't work if hidepid=1 or hidepid=2 is the proc mount option in use. This is not a default on the majority of distros out there.

edited Jul 07 '16 at 21:04

answered Jul 07 '16 at 20:05

Matthew Ife

116
1

Thanks Matthew, this is just the sort of thing I was looking for. – Joe Jul 07 '16 at 20:10
2

How would this work assuming an unprivileged adversary? – zymhan Jul 07 '16 at 20:34
1

I believe that @WildVelociraptor is correct and that your "solution" only works if you're root. From [proc.5.html](http://man7.org/linux/man-pages/man5/proc.5.html) "Sensitive files such as /proc/[pid]/cmdline and /proc/[pid]/status are now protected against other users." – Neil Smithline Jul 07 '16 at 20:56
You are wrong. If you read the man page properly, that only true when hidepid=1 or above is the mount option. Thats not the default on most distros. Try the program. I tested it explicitly with an unprivileged attacker against an unprivileged victim. – Matthew Ife Jul 07 '16 at 20:58
@MatthewIfe I can't at the moment, I'm on my mobile. Perhaps you should update your answer to mention the hidepid option to avoid confusion – Neil Smithline Jul 07 '16 at 21:03

How secure is it to use secret directory names to share files on unix?

2 Answers2