[linux-cifs-client] [PATCH] Remove information leak in Linux CIFS clientg

[Steve French]

Just merged into the cifs-2.6 tree, changing the last patch as you
just suggested to take out the logged path name.

On Jan 19, 2008 5:25 PM, Andi Kleen <andi at firstfloor.org> wrote:
> On Sat, Jan 19, 2008 at 04:55:53PM -0600, Steve French wrote:
> > On Jan 19, 2008 4:30 PM, Andi Kleen <andi at firstfloor.org> wrote:
> > > On Sat, Jan 19, 2008 at 04:06:57PM -0600, Steve French wrote:
> > > > The access denied message in the dmesg log reveals no more information
> > > > than strace on stat of a local file does (which also returns access
> > >
> > > You can't strace a process you don't own. And you might not be able
> > > to access the directory below which the file is.
> >
> > If you can't access the directory that the file is in then you get
> > access denied on stat of the file (local over ext3 or remote over
> > cifs) - it does not tell you anything about whether the file existed
> > or not.  If you do "stat
> > /mnt/dir-with-0700-perm/file-which-does-not-exist"  I get access
> > denied.  I don't think that it really tells you anything interesting
> > since the same error comes back whether or not the file existed.
>
> The problem is that the file name ends up in the log for everybody to
> read even if they're totally unrelated. So if someone in a protected directory
> tree where they have access to does something that is denied the
> file names will still leak to everybody else to the log.
>
> e.g. more concrete example. you do something and get that message.
>
> Now even 'nobody" running in a chroot will know that you tried
> that and that at least parts of the file name likely exist.
>
> That is an information leak and imho a privacy problem.
>
> > Other unexpected errors (e.g. -EIO) should be logged because they
> > indicate possibly severe problems with the network, but also don't
> > tell you anything about whether the file exists.
>
> Sure errors should be logged, but not with path names.
>
> -Andi
>



-- 
Thanks,

Steve