linux-kernel - Re: O_DIRECT question

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 14 Jan 2007 10:39:52 -0500
From:	Bill Davidsen <davidsen@....com>
To:	Michael Tokarev <mjt@....msk.ru>
CC:	Chris Mason <chris.mason@...cle.com>,
	dean gaudet <dean@...tic.org>, Viktor <vvp01@...ox.ru>,
	Aubrey <aubreylee@...il.com>, Hua Zhong <hzhong@...il.com>,
	Hugh Dickins <hugh@...itas.com>, linux-kernel@...r.kernel.org,
	hch@...radead.org, kenneth.w.chen@...el.com, akpm@...l.org
Subject: Re: O_DIRECT question

Michael Tokarev wrote:
> Bill Davidsen wrote:

> If I got it right (and please someone tell me if I *really* got it right!),
> the problem is elsewhere.
> 
> Suppose you have a filesystem, not at all related to databases and stuff.
> Your usual root filesystem, with your /etc/ /var and so on directories.
> 
> Some time ago you edited /etc/shadow, updating it by writing new file and
> renaming it to proper place.  So you have that old content of your shadow
> file (now deleted) somewhere on the disk, but not accessible from the
> filesystem.
> 
> Now, a bad guy deliberately tries to open some file on this filesystem, using
> O_DIRECT flag, ftruncates() it to some huge size (or does seek+write), and
> at the same time tries to use O_DIRECT read of the data.

Which should be identified and zeros returned. Consider: I open a file 
for database use, and legitimately seek to a location out at, say, 
250MB, and then write at the location my hash says I should. That's all 
legitimate. Now when some backup program accesses the file sequentially, 
it gets a boatload of zeros, because Linux "knows" that is sparse data. 
Yes, the backup program should detect this as well, so what?

My point is, that there is code to handle sparse data now, without 
O_DIRECT involved, and if O_DIRECT bypasses that, it's not a problem 
with the idea of O_DIRECT, the kernel has a security problem.
> 
> Due to all the races etc, it is possible for him to read that old content of
> /etc/shadow file you've deleted before.
> 
>> I do have one thought, WRT reading uninitialized disk data. I would hope
>> that sparse files are handled right, and that when doing a write with
>> O_DIRECT the metadata is not updated until the write is done.
> 
> "hope that sparse files are handled right" is a high hope.  Exactly because
> this very place IS racy.

Other than assuring that a program can't read where no program has 
written, I don't see a problem. Anyone accessing the same file with 
multiple processes had better be doing user space coordination, and gets 
no sympathy from me if they don't. In this case, "works right" does not 
mean "works as expected," because the program has no right to assume the 
kernel will sort out poor implementations.

Without O_DIRECT the problem of doing ordered i/o in user space becomes 
very difficult, if not impossible, so "get rid of O_DIRECT" is the wrong 
direction. When the program can be sure the i/o is done, then cleverness 
in user space can see that it's done RIGHT.

-- 
bill davidsen <davidsen@....com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/