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: <alpine.DEB.1.10.0808171620260.12859@asgard.lang.hm>
Date:	Sun, 17 Aug 2008 16:24: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:

>>>> 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.
>
> ...can and will use it as an IPC. So we need to modify some
> applications.
>
> Rather than modify all the applications using mmap (you can't tell if
> the other side is going to use it for shared memory... right?), we
> could simply modify all the Windows-facing applications using mmap.
>
>> if you are worried about the IPC aspects, all you can do is forbid it,
>
> Can you automatically tell if applications are using mmap for IPC?

no, but can you tell at the time of the mmap command if anyone has it 
opened for writing? if you can then you can just not allow the mmap in 
thid case (policy decision by userspace, as such it can try to look at 
what other programs are accessing it via mmap to decide if it should allow 
it or not)

> BTW in another mail you wanted to include /var/log/syslog from
> scanning. You should not be doing that if syslog is exported to
> Windows systems. Of course, you can get away with scanning syslog when
> Windows client tries to read it, which should be acceptable...

I listed that as an example of what I would consider a sane policy. by 
doing the checking is a userspace library different binaries can be linked 
against different libraries by the sysadmin/distro to decide which ones 
need to do what checking. there's nothing inherent in the mechanism that 
foces the policy in any direction.

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