Message-ID: <e7d8f83e0808160438y73c5b24cl306144f512ef6013@mail.gmail.com>
Date:	Sat, 16 Aug 2008 21:38:30 +1000
From:	"Peter Dolding" <oiaohm@...il.com>
To:	"Theodore Tso" <tytso@....edu>, "Peter Dolding" <oiaohm@...il.com>,
	"Arjan van de Ven" <arjan@...radead.org>, david@...g.hm,
	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 Sat, Aug 16, 2008 at 7:39 PM, Theodore Tso <tytso@....edu> wrote:
> On Sat, Aug 16, 2008 at 03:19:43PM +1000, Peter Dolding wrote:
>> 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.
>
> Huh?  What are you talking about?  In Linux just about all of the
> serious filesystems the only caching for file data happens in the page
> cache layer.  So what you're saying doesn't make much sense, unless
> you're talking about the user space samba daemon --- but even there,
> Samba doesn't do any shortcut routing of data; as far as I know
> everything goes from Samba, into the filesystem, before it gets served
> out to other clients via Samba back out from the filesystem.  So
> everything goes through the page cache.

These file system caches are internal permissions caching points where
the driver decides what you can and cannot see.  Before conversion to
normal inode structs.  Others have own internal buffers for transfers.
  Yes everything is stored on the page cache but it does not have to
be in any shape you would normally id as a file.  I have a bad habit
of putting buffers and caches in the same box.  Thinking that some
file system drivers are smart enough to use the same buffer if they
get the same request twice.  So even that a file may have been
rejected due to being a virus it can still be sitting around in memory
in a buffer not cleared.
>
>> 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
>
> No one else is taking about checking permissions; I thought this was
> all about file *data* that we've been talking about.
>
> If your argument means that we have to take every single
> $Proprietary_OS's wacky permissions system, and push them into to core
> Linux system so the AV system can evaluate it, I'm pretty sure
> everyone is going to vomit all over such a proposal (and over you).
>
Thrown away data is not only Proprietary OS Ted.  There are permssions
on mac amiga and many others but there not the only issues of stuff
being made invisible by the driver.

There are fully documented file systems that have hidden streams you
cannot see without passing them correct flags.

UDF undelete and unhide options and ISO showassoc  makes more files
appear on those formats.  UDF and ISO hidden files are one of the
nasties.  AV scans the disk calls it clean.  Remount it with the other
options enabled nice little bit of magic hidden infected files could
turn up.   Black holed.

What is the worst bit about this knowing the luck of this world.
Some people will mount the disks/partitions with the option that
displays the virus with a OS without a anti-virus because another
computer said the disk was clean.

Ext2/3/4 nouser_xattr and noacl don't remove the permissions just
remove the map threw from the driver.

Now there is also the up coming issues of www.nilfs.org and other
continual snap shotting file systems.   If cannot see the permissions
the filesystem drivers are processing and the data those permissions
are causing to be hidden.  The best you can do at the moment see that
the flags to make the data invisible or visible is set and ask user to
remount drive just so you can scan it.  Continual snap shotting file
systems users are not going to take to being asked to stop what they
are doing so anti-virus can remount the filesystem a few million times
to make sure the disk is clean of viruses.  Virus scanning takes long
enough without doing that.

So either anti-virus companies will have to build custom interfaces
that bugs users to handle UDF ISO and any other continual snap
shotting file system that appears.  Or we improve the core so software
that needs to can see everything on a file system can to the level the
drivers support so when a drive is truly 100 percent scanned it is 100
percent scanned.   No missing files.  Root user really does not help
against hidden files that the driver is hiding due to obeying hidden
permissions.

I was not clear enough.   Some of the hidden permissions that don't
appear in the inode system cause files to disappear from existence on
the file system until that filesystem is mounted with the right
option.   Or in the case of a continual snap shotting filesystem virus
could be still there in a roll back just like windows.  So user
deleting the virus never got rid of it.  So months latter the same
virus can turn up again and again.  If it just happens to line up with
the user have the anti-virus down it gets a second chance that it
should have never got.  Surface scanning from the inode system is
kinda blind to a lot of hidden spots on quite a few file systems.

Some of the hidden permissions can be handy as well for HIDS to tell
if anyone has been on a file system since it was last there too.  If a
not used acl or user xattr been touched someone else has been on the
filesystem since it was last left.

There is a nice void space where viruses can nicely hide out at the
moment.  Issue is more void space is going to be made unless some
system is designed to handle file systems with these non translatable
permissions and options hidden permissions.  Yes currently hack around
issue of posix permissions not providing every option has been adding
a mount option.  More dynamic options for handling the issue of non
translatable permissions should be possible and less user disrupting.

Can you now see the sign of trouble I have been trying and trying to
put into words.   I can see the problem.   Putting it in the right
words has been a battle.

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/

Powered by blists - more mailing lists