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 15:47:41 -0700 (PDT)
From:	david@...g.hm
To:	Pavel Machek <pavel@...e.cz>
cc:	Eric Paris <eparis@...hat.com>, Theodore Tso <tytso@....edu>,
	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,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon
 access scanning

On Mon, 18 Aug 2008, Pavel Machek wrote:

> Hi!
>
>> And I still don't get this 'mmap problem' that I don't solve that
>> libmalware magically solves.  What?  don't use mmap?  I certainly hope
>> not.
>
> Don't use mmap, it is as simple as that. AFAICS mmap(MAP_SHARED) --
> which is basically shared memory -- is fundamentally incompatible with
> reliable virus scanning.
>
> ...or do you have a reasonable solution for mmap?


mmap has a few different problems

1. intercepting reads and writes to take action at that time

2. the fact that two programs can use it as an inter-process communication 
mechanism.

if you are worried about the IPC aspects, all you can do is forbid it, 
along with shared memory, pipes, network connections, etc. none of these 
provide you with a 'final result' that can be scanned, and as others have 
pointed out there are too many ways to do things that get assembled by the 
far side to try and catch all malware in them.

as for intercepting reads and writes. the approach I outlined addresses 
this by having the kernel mark thefile as dirty if any writes happen, and 
checking the file status at the time of doing the mmap instead of trying 
to do it when the file is accessed after the mmap.

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