This came out of one of our internal security review. I thought I would post it here for beware sake.
DirectoryInfo’s Name property currently requires no permission checks in and of itself, though you do need Read permission to construct a DirectoryInfo in the first place. DirectoryInfo’s FullName property requires path discovery permission to the fully qualified path, and the Parent property (which returns a new DirectoryInfo) requires Read and PathDiscovery permission to the parent directory.
Isolated storage stores information in a cryptographically strong name to protect the name of the directory from the assembly that has permission to read & write in that directory. The application must not be able to get the fully qualified path to isolated storage. This is a bit counter-intuitive, but may be important in helping prevent cross-zone scripting attacks or other similar attacks.
The lack of any permission checks here on the Name property could be a vulnerability for apps that create directories within isolated storage or some other containment-based virtual directory root (ASP.NET does some amount of restriction as well.)
The strange thing about path discovery and a scenario like isolated storage is that you have permission to a relative directory. So if you have something like c:\a\b\c, we may prevent you from discovering c:\a, but allow you to read .\b and .\b\c. We currently have no mechanism for handling relative directories in a pleasant manner with respect to permission checks – we always fully qualify, and we can’t hand back a name like that. This seems interesting, but too complex to solve right now.
1) The Name property could demand path discovery on the directory itself
2) The Name property could demand read permission on the parent directory to support isolated storage
3) Invent some new functionality for a virtual root directory to help with sandboxing
4) Document that the Name property of a DirectoryInfo requires no permission (beyond the read permission to the directory necessary to construct the DirectoryInfo), and can give out the directory name. So do not hand out a DirectoryInfo to your protected directory with a cryptographically secure name. Instead, if you must do this, create a dummy directory for the un-trusted code’s use.
To first appearances, 1 seems to be the most intuitive, but doesn’t solve isolated storage and isn’t exactly what we want since we’re not handing back a fully qualified path, but only a portion of the path. 2 would solve the problem for isolated storage, but seems like an awkward way of protecting a path name, saying path discovery permission is no longer sufficient to discover even the name of a directory, let alone a fully qualified path. 3 sounds interesting for a future version. 4 seems like the best choice for now.