linux-kernel - Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interfaceforon access scanning

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: <48998BA3.3080804@sun.com>
Date:	Wed, 06 Aug 2008 07:31:47 -0400
From:	David Collier-Brown <davecb@....com>
To:	Peter Dolding <oiaohm@...il.com>
Cc:	"Press, Jonathan" <Jonathan.Press@...com>,
	Rik van Riel <riel@...hat.com>, Greg KH <greg@...ah.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Eric Paris <eparis@...hat.com>, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interfaceforon
 access scanning



Peter Dolding wrote:
 > My main issue is TALPA, dazuko and so on of Anti-Virus Filesystem
> monitoring are all going to break anyhow when
> http://lwn.net/Articles/251224/ Credentials get added and common
> filesystem caching gets added.
> 
> You want to change a permissions on a file/object before its opened.
> So does the Credential user space daemon on file systems that cannot
> store secuirty information.  We only really need 1 location in the
> source base for this.  Expand Credentials slightly to allow anti
> viruses to operate by by problem.   Even better when FS-Cache can sit
> on top of Credentials correctly no need for anti virus software to
> have independent caching of blocked and allowed files.  FS-Cache picks
> a large amount of this up.
> 
> Basically TALPA, dazuko and so on of Anti-Virus Filesystem monitoring
> don't fit in the future design of Linux.   All they will be is
> duplication of a existing interface.  A interface that complete avoids
> the stacking issue.

Then in a real sense you've solved much of their problem for them (;-))
After this comes engineering, so that they can re-use the scanning 
mechanisms they already have, but from a different caller.

The requirements are probably that they know
- is this an open for read or write (somewhat less time-sensitive)?
- is the data present, or do we have to wait?
- if so, for what?
as of the time they start looking at the file.  Having a race-free
mechanism using credentials and RCU is, IMHO, A Really Good Thing.

Another thing they and we will likely need is a way to discover
if a file is inacessable due to an AV operation, and if the time
it has been inacessable is less than or equal to a scanning
upper bound by file size or beyond it.  The latter is for repair
of broken state introduced by the AV process failing.

--dave

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

-- 
David Collier-Brown            | Always do right. This will gratify
Sun Microsystems, Toronto      | some people and astonish the rest
davecb@....com                 |                      -- Mark Twain
cell: (647) 833-9377, bridge: (877) 385-4099 code: 506 9191#
--
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/