Bug 117987

Summary: read(2) on directories might leak filenames of deleted files
Product: Base System Reporter: Pierre Riteau <pierre.riteau>
Component: kernAssignee: 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
On FreeBSD, any user can open(2) and read(2) a directory when he has read rights to it. read(2)ing a directory dumps the content of the inode of that directory, which might leak filename of deleted files.
Those filenames may be secret.

Fix: 

On OpenBSD read(2)ing a directory always returns 0 (end-of-file) (on a FFS1 filesystem).
How-To-Repeat: $ cd /home/pierre
$ ls
.               .history        .login_conf     .profile
.              .lesshst        .mail_aliases   .rhosts
.cshrc          .login          .mailrc         .shrc
$ chmod 700 . # no one should list the content of this directory now
$ touch secretfilename # no one should see this filename
$ rm secretfilename
$ chmod 755 . # ok, I can make it public, secretfilename is gone

Another user can now do :
$ cat -v /home/pierre
Ym
^@^L^@^D^A.^@^@^@Xm
^@^L^@^D^B..^@^@Zm
^@^P^@^H^F.cshrc^@M-L[m
^@^P^@^H^F.login^@M-L\m
^@^T^@^H^K.login_conf^@]m
^@^P^@^H^G.mailrc^@^m
^@^T^@^H^H.profile^@M-+M-^WM-L_m
^@^P^@^H^E.shrc^@M-^WM-L`m
^@^X^@^H^M.mail_aliases^@OM-Bam
^@^P^@^H^G.rhosts^@bm
^@^T^@^H^H.history^@M-;^NM-Mcm
^@D^A^H^H.lesshst^@^K^MM-Mdm
^@0^A^H^Nsecretfilename^@M-B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

and he sees the secretfilename.
Comment 1 K. Macy freebsd_committer freebsd_triage 2007-11-16 17:44:12 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. 


Comment 2 K. Macy freebsd_committer freebsd_triage 2007-11-16 17:44:12 UTC
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.
Comment 3 K. Macy freebsd_committer freebsd_triage 2007-11-16 18:13:56 UTC
State Changed
From-To: feedback->open


Robert has committed to commenting. 


Comment 4 K. Macy freebsd_committer freebsd_triage 2007-11-16 18:13:56 UTC
Responsible Changed
From-To: cperciva->rwatson


Robert has committed to commenting.
Comment 5 Robert Watson freebsd_committer freebsd_triage 2008-01-13 18:35:18 UTC
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.
Comment 6 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:44:49 UTC
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.
Comment 7 Kyle Evans freebsd_committer freebsd_triage 2020-12-30 17:17:18 UTC
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.