From nobody@FreeBSD.org  Sun Nov 11 20:18:36 2007
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 4F04416A418
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 11 Nov 2007 20:18:36 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 2A9B013C4B0
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 11 Nov 2007 20:18:36 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.1/8.14.1) with ESMTP id lABKIBET057060
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 11 Nov 2007 20:18:11 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.1/8.14.1/Submit) id lABKIBDj057059;
	Sun, 11 Nov 2007 20:18:11 GMT
	(envelope-from nobody)
Message-Id: <200711112018.lABKIBDj057059@www.freebsd.org>
Date: Sun, 11 Nov 2007 20:18:11 GMT
From: Pierre Riteau <pierre.riteau@free.fr>
To: freebsd-gnats-submit@FreeBSD.org
Subject: read(2) on directories might leak filenames of deleted files
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         117987
>Category:       kern
>Synopsis:       read(2) on directories might leak filenames of deleted files
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    rwatson
>State:          analyzed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Nov 11 20:20:00 UTC 2007
>Closed-Date:    
>Last-Modified:  Sun Jan 13 18:39:10 UTC 2008
>Originator:     Pierre Riteau
>Release:        FreeBSD 7.0-BETA2
>Organization:
>Environment:
FreeBSD freebsd.localdomain 7.0-BETA2 FreeBSD 7.0-BETA2 #0: Fri Nov  2 16:47:33 UTC 2007     root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
>Description:
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.
>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.
>Fix:
On OpenBSD read(2)ing a directory always returns 0 (end-of-file) (on a FFS1 filesystem).

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: kmacy 
State-Changed-When: Fri Nov 16 17:44:12 UTC 2007 
State-Changed-Why:  

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 
Responsible-Changed-By: kmacy 
Responsible-Changed-When: Fri Nov 16 17:44:12 UTC 2007 
Responsible-Changed-Why:  

I don't think a user should have read access to a directory that is considered private.   
I would like to just close this.  


http://www.freebsd.org/cgi/query-pr.cgi?pr=117987 
State-Changed-From-To: feedback->open 
State-Changed-By: kmacy 
State-Changed-When: Fri Nov 16 18:13:56 UTC 2007 
State-Changed-Why:  

Robert has committed to commenting. 


Responsible-Changed-From-To: cperciva->rwatson 
Responsible-Changed-By: kmacy 
Responsible-Changed-When: Fri Nov 16 18:13:56 UTC 2007 
Responsible-Changed-Why:  

Robert has committed to commenting.  

http://www.freebsd.org/cgi/query-pr.cgi?pr=117987 
State-Changed-From-To: open->analyzed 
State-Changed-By: rwatson 
State-Changed-When: Sun Jan 13 18:35:18 UTC 2008 
State-Changed-Why:  
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. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=117987 
>Unformatted:
