Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I noticed that when a user is working in a directory to which he does not have read permission that using cd produces different error messages, depending on whether or not a subdirectory exists:

$ ls
ls: cannot open directory .: Permission denied
$ cd nonexistentdirectory
-bash: cd: nonexistentdirectory: No such file or directory
$ cd existingdirectory
-bash: cd: username: Permission denied

It raises the question: Is the fact that a user can brute-force a directory listing this way without read permission a security flaw? If so, is it a flaw of UNIX or Bash?

share|improve this question
    
I'm not quite sure I understand the question. In what way can the user "brute-force" a listing in your example? The shell does what it's supposed to do: deny access when read rights aren't there, and inform the user that the directory he wants to cd to doesn't exist. –  schaiba Jan 24 '13 at 19:08
2  
Schaiba, those are two different kinds of information: In neither case can the user access the subdirectory, but he can tell whether or not the subdirectory exists at all by the error message, which, if it's true, completely bypasses the read permission bit on the parent directory. –  BlueBomber Jan 24 '13 at 19:13
1  
Schaiba, just to elaborate: If a user can generate a list of file names (this is the brute-force part) and test each one, the error message could be used to filter the list so it only contains existing subdirectories. –  BlueBomber Jan 24 '13 at 19:18
add comment

2 Answers

This is not a security flaw, in that the feature is working the way it's supposed to work. (Given that this feature pretty much arose by accident, that's no surprise.) It may be that your expectations don't quite match what the feature really does.

When a user has the execute permission on a directory but not the read permission, the user can access any entry in the directory provided he knows its name. This access includes all metadata about the entry, including its name, its type, its size, its dates, etc. So the user can distinguish a nonexistent entry from an existing entry whose content he may not be able to access.

The names of the entries act like passwords. If you know the password, you can reach the entry. There may be additional access restrictions on the entry, but that's an unrelated matter. You can always break password authentication by brute force by trying all possible passwords.

If you don't want to reveal anything about the entries in an --x directory, use unguessable names (i.e. random names that are long enough).

share|improve this answer
add comment

Yes, you could regard it as a security flaw in how Unix file and directory permissions are defined and implemented. It's a compromise; it enables you, for example, to grant users access to a directory deep inside a restricted hierarchy if they know the path.

The workaround is to nest restricted directories so that you have to guess several components before you can access really sensitive information. But of course, this doesn't really add security, just obscurity.

The root user can bypass any of these restrictions anyway, so it's nevertheless not particularly secure. If you want reasonable security, a multi-user system is probably not where you should be.

share|improve this answer
    
Tripleee, yes, nesting restricted directories does increase obscurity, not security, but a user trying by brute force to find out which subdirectories he has permissions to access is a different situation than a user being able to obtain a list of existing subdirectories, irrespective of their permissions. –  BlueBomber Jan 24 '13 at 22:11
    
OK, but this brute-forcing for one file means trying all 255-long possible filenames. Easier to brute-force your password. Or use the technique described in xkcd.com/538. –  vonbrand Jan 24 '13 at 22:41
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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