linux-kernel - Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface for on 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]

Date:	Thu, 7 Aug 2008 02:57:30 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	tvrtko.ursulin@...hos.com
Cc:	Eric Paris <eparis@...hat.com>, linux-kernel@...r.kernel.org,
	malware-list@...ts.printk.net
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface for	on access scanning

On Wednesday 06 August 2008 21:29, tvrtko.ursulin@...hos.com wrote:
> Nick Piggin <nickpiggin@...oo.com.au> wrote on 06/08/2008 12:10:58:

> > > code so what am I missing?
> >
> > Maybe... but that's not the same as what requirement 5 calls for.
>
> I see what you mean, it should have been worded better. Nevertheless that
> is what was intended by it - to enable caching only on filesystems where
> it is safe to do so.

That is exactly what you cannot do. Otherwise you have to rewrite
filesystems not to use the pagecache, and probably have to do disallow
or do some horrible hacks to support mmap.

The requirement you actually intend is more like what you said before,
along the lines of "file can't be changed in given set of circumstances".


> > But depending on exactly what semantics you really call for, it can get
> > tricky to account for all of pagecache. Writes can happen through page
> > tables or get_user_pages. True that a process has to at some point have
> > write permission to the file, but the cache itself could be modified
> > even after the file is closed and all mmaps disappear.
>
> I don't have a very good understanding of the VM subsystem I must admit.
> So in other words with the current kernel file modification time is not
> necessarily correct - it represents when the file was last opened for
> modification, not when it was actually modified? (While those two points
> in time can be arbitrarily separated)

It is a best effort thing. When you start mmapping, that allows
get_user_pages, which in turn may be able to take pages and modify
them at fairly arbitrary points in time.


> How would I use those methods for file modification? I am curious to make
> a test case..

Even just with mmap (we do a much better job of it now, but) you
can probably write to a file after mtime if you write to already
dirty pages.

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