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: <20080814085740.35b32633@infradead.org>
Date:	Thu, 14 Aug 2008 08:57:40 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Eric Paris <eparis@...hat.com>
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 Thu, 14 Aug 2008 10:12:13 -0400
Eric Paris <eparis@...hat.com> wrote:

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

you could stretch things and report -EIO.

> 
> The idea of multiple concurrent outstanding async notifications is
> going to be much more difficult to code, but hey, who am I to

well... do you really need a response?
you could just write it to a netlink socket...

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

or fire-and-forget.
> 
> 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?

I think we need to sort the interface issue on this for sure, and
probably from the start...

> 


-- 
If you want to reach me at my work email, use arjan@...ux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
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/