0

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?

migrated from serverfault.com Jul 7 '16 at 19:38

This question came from our site for system and network administrators.

  • You didnt shared it, it's a misconception you have, you simply hidded it. Shared would mean with samba/ftp in example – yagmoth555 Jul 7 '16 at 18:36
  • 2
    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 7 '16 at 20:57
  • @NeilSmithline if you tested my program you'll find that assertion to be false. – Matthew Ife Jul 7 '16 at 21:01
  • in short: it's not the absolute worst thing ever, but there are better ways of doing it. – dandavis Jul 7 '16 at 22:54
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.

  • Thanks Matthew, this is just the sort of thing I was looking for. – Joe Jul 7 '16 at 20:10
  • 2
    How would this work assuming an unprivileged adversary? – zymhan Jul 7 '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 "Sensitive files such as /proc/[pid]/cmdline and /proc/[pid]/status are now protected against other users." – Neil Smithline Jul 7 '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 7 '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 7 '16 at 21:03
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.

  • 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 7 '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 7 '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 7 '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 7 '16 at 19:10
  • 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 7 '16 at 21:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.