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
| ||
|
Date: Sun, 17 Aug 2008 12:33:20 +0200 (CEST) From: "Rob Meijer" <capibara@...all.nl> To: david@...g.hm Cc: "Peter Dolding" <oiaohm@...il.com>, "Theodore Tso" <tytso@....edu>, "Arjan van de Ven" <arjan@...radead.org>, rmeijer@...all.nl, "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, 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. Rob -- 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