linux-kernel - Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon 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:	Sat, 16 Aug 2008 15:19:43 +1000
From:	"Peter Dolding" <oiaohm@...il.com>
To:	"Arjan van de Ven" <arjan@...radead.org>
Cc:	david@...g.hm, rmeijer@...all.nl,
	"Alan Cox" <alan@...rguk.ukuu.org.uk>, capibara@...all.nl,
	"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,
	"Pavel Machek" <pavel@...e.cz>
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon access scanning

On Sat, Aug 16, 2008 at 2:09 PM, Arjan van de Ven <arjan@...radead.org> wrote:
> On Sat, 16 Aug 2008 13:57:50 +1000
> "Peter Dolding" <oiaohm@...il.com> wrote:
>> Anti-Virus has been for years about chasing the threat.   Lets try to
>> get in front of it.  You thread model needs a major update its
>> incomplete.
>>
>
> The problem TALPA is trying to solve is only part of the puzzle.
> Everyone recognizes that. It's a very relevant part of the puzzle (in
> corporate context at least), but it's very much so not a complete
> puzzle. Does that mean we shouldn't deal with this just because it's
> incomplete? Absolutely not!

TALPA idea I agree with.  As the long term forever solution I don't
agree with due to its location.

Lets look at the general disk to memory path.

[file system driver]
[file system drivers caches]
[inode's]  TALPA links in here and basically runs its own scan cache.

Long term TALPA need to move from the inode layor down and the design
of the file system path needs to change.

[file system driver]
[generic file system cache]  TALPA enters here and spreads.
[inodes]

generic file system cache built in a way that it can store all the non
linux permission and related data that the file system driver needs.

Reasons
1. That shape even if file system extra permissions are decided to be
kept hidden from the rest of Linux anti-virus can scanning can see it.
2. Everything that is in memory  is checked.
3. Infected files can be removed from consuming memory in the file
system cache.  So a raw memory scan of Linux will not trip on viruses
still being present in memory even that TALPA is running.  False
positive suggesting TALPA has failed is possible due to its current
location.
4 share caching of passed and failed with the file system cache.

1 virus removed from a file system cache could equal the complete
memory price of running TALPA.

Its TALPA location I have major issue with.   Being blind to full set
of information to make a judgement call is the other.

I see it in the same cat a unionfs fine as a side patch to main
kernel.   Not fine to enter main kernel due to being in the wrong
place.  Its the balancing act if we let TALPA will it ever develop
down to the location where it should be?

Can you say 100 percent that TALPA is in the right location for what
it is doing.   If it is not its a good temp fix until we can get
developed the solution in the correct location.  Temp fixes normally
never get main line.

Be truthful its simply in the wrong place.   Getting it to the correct
location for most effective memory usage and giving a virus the least
ammont of distance into linux.  Scanned and 100 percent booted out of
memory.  Other thing some file system drivers also keep stuff in there
cache independent to inodes.   So spots at moment can be double
scanned even that the complete time everything was in memory because
the inode was freed and the file system cache still had it.

You want the most effective use of CPU? if no go head with TALPA.

Current TALPA fails too many holes and flaws.   All caused by 1 thing
its location.   Yes its a major job to move it to the correct location
its a major file system operation rework.

TALPA unfortunately is like trying to build a house on quick sand.
Foundations it needs to work correctly and 100 percent effectively
currently not present.   The quick sand of many file system caches had
to come back and bite at some point.  The blocking of seeing all the
file system permissions also had to come back and bite at some point.

Fix the foundations TALPA idea will be solid for its section of the
puzzle.   Sticking head in sand and saying the foundations don't have
major issues is just fooling to your self.  LIM and others patches
trying to be put in also have the same quick sand issue.

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