LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Steve French <smfrench@gmail.com>
Cc: Andi Kleen <andi@firstfloor.org>, simo <idra@samba.org>,
	linux-kernel@vger.kernel.org, linux-cifs-client@lists.samba.org,
	samba-technical@lists.samba.org
Subject: Re: [linux-cifs-client] [PATCH] Remove information leak in Linux CIFS clientg
Date: Sun, 20 Jan 2008 00:25:49 +0100	[thread overview]
Message-ID: <20080119232549.GA6275@one.firstfloor.org> (raw)
In-Reply-To: <524f69650801191455g5eab5edfw80f27136662a465c@mail.gmail.com>

On Sat, Jan 19, 2008 at 04:55:53PM -0600, Steve French wrote:
> On Jan 19, 2008 4:30 PM, Andi Kleen <andi@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

  reply	other threads:[~2008-01-19 23:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-19  4:55 [PATCH] Remove information leak in Linux CIFS client Andi Kleen
2008-01-19  8:18 ` [linux-cifs-client] " simo
2008-01-19 22:06   ` Steve French
2008-01-19 22:30     ` [linux-cifs-client] [PATCH] Remove information leak in Linux CIFS clientg Andi Kleen
2008-01-19 22:55       ` Steve French
2008-01-19 23:25         ` Andi Kleen [this message]
2008-01-20  0:32           ` Steve French

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080119232549.GA6275@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=idra@samba.org \
    --cc=linux-cifs-client@lists.samba.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=samba-technical@lists.samba.org \
    --cc=smfrench@gmail.com \
    --subject='Re: [linux-cifs-client] [PATCH] Remove information leak in Linux CIFS clientg' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).