Summary: | read(2) on directories might leak filenames of deleted files | ||
---|---|---|---|
Product: | Base System | Reporter: | Pierre Riteau <pierre.riteau> |
Component: | kern | Assignee: | Kyle Evans <kevans> |
Status: | Closed FIXED | ||
Severity: | Affects Only Me | CC: | kevans |
Priority: | Normal | ||
Version: | 7.0-BETA2 | ||
Hardware: | Any | ||
OS: | Any |
Description
Pierre Riteau
2007-11-11 20:20:00 UTC
State Changed From-To: open->feedback I don't think a user should have read access to a directory that is considered private. I would like to just close this. Responsible Changed From-To: freebsd-bugs->cperciva I don't think a user should have read access to a directory that is considered private. I would like to just close this. State Changed From-To: feedback->open Robert has committed to commenting. Responsible Changed From-To: cperciva->rwatson Robert has committed to commenting. State Changed From-To: open->analyzed This has long been considered a BSD feature, but it does have downsides. In particular, Common Criteria requires that data deleted using an operating system interface not be exposed to unprivileged processes (similar to memory zeroing requirements). I'm unclear on whether applications have come to depend on read(2) working on directories, but one can certainly imagine that they might have (perhaps dump?). I think the right path forward here is to introduce a new sysctl that controls whether or not direct directory read is permitted for unprivileged processes. We can try setting it by default and fall back to having it be a policy option if that doesn't work out. I don't have a patch for this currently, but will investigate doing that sometime this year. This is made somewhat tricky because we don't distinguish VREAD and VREADDIR with our vaccess() interface, so we can't just do it in vaccess() without modifying file systems to also make the distinction. batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed. This is no longer the case as of r361798 (add security.bsd.allow_read_dir, default unreadable) + r361799 (restrict the knob to only allowing system root to read directories). This was partially MFC'd to stable/12 prior to 12.2 as r363017; just the knob was MFC'd, and it still defaults to "disallow" -- the difference being that in 12.2 the knob being turned to allow it will allow any user to read a directory to match historical behavior. I am closing this as FIXED because no further action will be taken at this point. |