Re: XFS information leak during crash

[Jan Kasprzak <kas@fi.muni.cz>]

Nathan Scott wrote:
: > The result is that those files contain data from random blocks on the
: > disk (e.g. from previously deleted files). This can have security/privacy
: > implications - users can see the contents of other users' old files.
: 
: If you think you have found a security issue, it would be courteous
: to at least discuss this with the maintainers first.

	Well, I think while it is a security issue, it is not serious
enough to make it secret (it is not exploitable by anyone except those
who are able to crash the machine).

: And since you
: are a frequent linux-xfs list poster too, it seems a bit odd that
: you're reporting this on linux-kernel instead... *shrug*, whatever.

	I am sorry for this one - I am not subscribed to linux-xfs.
Next time I will post to linux-xfs first.
: 
: This issue affects every filesystem, right?  Or are you claiming its
: only XFS affected here?  Have you run your parallel-buffered-writers
: test case on any other filesystems?  I'd be interested in the results,
: in particular, with all of the data=xxx modes of other filesystems.
: 
	I will do this tomorrow or the day after and post the results.

: > either). Does XFS support a something like ext3's "data=ordered" mount
: > option? 
: 
: No, it doesn't.
: 
	OK.

: > Otherwise it is pretty unusable on multi-user systems.
: 
: That's a ridiculous assertion.  While this small metadata vs. buffered-
: data-write window exists on _any_ filesystem not using a data=ordered/
: data=journaled mode (which I believe is quite a common mode of operation
: even on filesystems that offer those modes),

	As for ext3, I believe the vast majority of ext3 filesystems
run in data=ordered mode. But yes, the same problem affects all filesystem
except those running in data=ordered/journal mode.

: it is impossible to exploit
: this in any sane way.  You'd think people on a multi-user system might
: actually notice the machine being frequently rebooted while you try to
: tickle this window to get at "interesting" uninitialised freespace, no?

	Yes, of course. However, the issue is probably much worse
on XFS, because on XFS it probably affects not only the files being
created/extended, but also the files being rewritten. Most other
filesystems rewrite the files in-place, so when you rewrite the file,
even with data=writeback you get only the mix of the old and new
contents. Not somebody else's random data.

	This particular problem was that one of my users apparently opened
his TeX document just to fix few typos, and ended up with the file which
contained some part of a shell script and some binary data :-(

	I agree this is hard to exploit on purpose, however it can still
leak a sensitive data. For example, this particular server runs also
a mail server for ~2200 users, so a private mail can end up in somebody
else's files.

: Having said that, a data=ordered mode for XFS would be a nice feature.
: It just hasn't reached the top of our priority list, and its not been
: offered up as a patch by anyone yet.  If anyone's interested in writing
: this, they should coordinate with hch and myself - there's a fair bit
: of I/O path work being done at the moment, which in the end will make
: a data=ordered mode alot easier to implement.

	OK, thanks! I wish I would have time to do more kernel hacking ...

-Yenya

-- 
| Jan "Yenya" Kasprzak  <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839      Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/    Journal: http://www.fi.muni.cz/~kas/blog/ |
> Specs are a basis for _talking_about_ things. But they are _not_ a basis <
> for implementing software.                              --Linus Torvalds <
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/