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, 17 Aug 2008 03:46:27 -0700 (PDT)
From:	david@...g.hm
To:	rmeijer@...all.nl
cc:	Peter Dolding <oiaohm@...il.com>, Theodore Tso <tytso@....edu>,
	Arjan van de Ven <arjan@...radead.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, capibara@...all.nl,
	Eric Paris <eparis@...hat.com>, Rik van Riel <riel@...hat.com>,
	davecb@....com, linux-security-module@...r.kernel.org,
	Adrian Bunk <bunk@...nel.org>,
	Mihai Don??u <mdontu@...defender.com>,
	linux-kernel@...r.kernel.org, malware-list@...ts.printk.net,
	Pavel Machek <pavel@...e.cz>
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon
      access scanning

On Sun, 17 Aug 2008, Rob Meijer wrote:

> On Sun, August 17, 2008 10:58, david@...g.hm wrote:
>> On Sun, 17 Aug 2008, Peter Dolding wrote:
>>> Instead swap across to the shorter white list to process and sort.
>>> Quarantining for black list scanning so performance of machine is hit
>>> with the least ammount.  Some areas like email, p2p for people using
>>> formats that should not contain macros or executable code white list
>>> scanning there is all that is needed before either blocking or asking
>>> user if black list scanning should be preformed or the file just
>>> deleted.  Lets close the door's on these malware writers without hurt
>>> end users any more than we have to.  What is the point of running a full
>>> black list across a file the user will delete because it was not what
>>> they thought it was.
>>
>> you are arguing with the wrong people here. we are not trying to define
>> the future of anti-virus technologies, we are trying to figure out how to
>> provide the hooks so that people and companies can go off and do the
>> research and experimentation and try different approaches.
>
> Given recent demonstrations that show how easy it apparently is to bypass
> blacklist base approaches, providing hooks to allow these blacklist
> approaches may I feel be rather futile. Focusing only on hooks for white
> list approaches in combination with hooks for least authority approaches
> like the powerbox would IMHO seem like a much more reasonable approach
> given the current state of things and knowledge concerning the blacklist
> technologies. Explicitly adding support for technology that is quickly
> becoming obsolete would seem like a waste of time and resources.

we are not providing hooks for blacklists or whitelists, we are providing 
hooks for scanning. it's up to the software that doesn the scanning to 
implement the blacklist or whitelist.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ