linux-kernel - Re: TALPA - a threat model? well sorta.

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]

Message-Id: <1218723133.3540.137.camel@localhost.localdomain>
Date:	Thu, 14 Aug 2008 10:12:13 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	linux-kernel@...r.kernel.org, malware-list@...ts.printk.net,
	andi@...stfloor.org, riel@...hat.com, greg@...ah.com,
	tytso@....edu, viro@...IV.linux.org.uk, alan@...rguk.ukuu.org.uk,
	peterz@...radead.org, hch@...radead.org
Subject: Re: TALPA - a threat model?  well sorta.

On Wed, 2008-08-13 at 14:39 -0700, Arjan van de Ven wrote:
> On Wed, 13 Aug 2008 14:57:44 -0400
> Eric Paris <eparis@...hat.com> wrote:
> 
> > > for the open() case, I would argue that you don't need synchronous
> > > behavior as long as the read() case is synchronous. I can imagine
> > > that open() kicks off an async scan, and if it's done by the time
> > > the first read() happens, no blocking at all happens.
> > 
> > An interesting addition.  Trying to keep these queues of events gets
> > much more complex, but if people really think the open to read race is
> > that important I've always said it wasn't impossible to close.
> 
> it's not "just" about open-to-read race.
> it's about open being non-blocking, and if read is not immediate, never
> hitting the latency at all.
> 
> The real point is that "read" is the actual point  you want to
> intercept, not "open" (you even wrote that in your description).. so
> why not just do that ?
>  The open case then is just a performance optimization.

I've been thinking about this more over night.  I really like the idea
for perf reasons but I'm scared of programs not expecting and thus
poorly handling -EACCESS from read.  Every program ever is going to
expect that back from open, but once you have the fd open its not
common.  

The idea of multiple concurrent outstanding async notifications is going
to be much more difficult to code, but hey, who am I to complain.  We
could have outstanding async scanning requests for any number of writes,
any number of closes, and any number of opens all at the same time.  The
current interface believes that every request out requires a response
but this type of interface basically requires some sort of coalescing.

Would you be opposed to a first patch round that did blocking
enforcement on open like we have today and do sync scanning (blocking or
return EWOULDBLOCK) on read if needed due to concurrent writes?

--
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/