Date:	Fri, 8 Aug 2008 00:21:10 +1000
From:	"Peter Dolding" <oiaohm@...il.com>
To:	"Pavel Machek" <pavel@...e.cz>
Cc:	tvrtko.ursulin@...hos.com,
	"Arjan van de Ven" <arjan@...radead.org>,
	"Press, Jonathan" <Jonathan.Press@...com>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	malware-list@...ts.printk.net, "Rik van Riel" <riel@...hat.com>
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon access scanning

On Thu, Aug 7, 2008 at 7:28 PM, Pavel Machek <pavel@...e.cz> wrote:
> Hi!
>
>> Problems with inotify as far as I know:
>>
>> You can't do something like inotify("/") (made up API) but you have to set
>> up a watch for every directory you wan't to watch. That seems like a waste
>> of resources.
>>
>> Then you get back a file name, if you wan't to report it or attempt* to
>> scan it you have to build a pathname yourself, which means you have to
>> maintain the whole tree of names in memory. Even bigger waste.
>>
>> When I say attempt to scan it above I mean that we are back into the
>> pathanme teritorry. It is not guaranteed we will be able to open and scan
>> using that pathname. I don't know what inotify reports with chroots and
>> private namespaces, but it can certainly fail with NFS and root_squash. So
>> it is less effective as well as being resource intensive.
>>
>> I think this is a good amount of flaws which shows inotify isn't really
>> ideal.
>
> Not ideal, but looks like good enough, and could certainly be
> improved. If it is secure-enough for you (I think it is), that looks
> like a way to go.
>
> (Plus, such improvements would actually be very welcome).
>                                                                        Pavel
>
My Issue API does not have to be made up.  The API kinda exists in
Credentials for a completely different use.

Issue with inotify its only monitoring.   No permission alteration to
block access.

Also its the wrong level.   I will explain why.

inotify is sitting on top of the vfs.   Ok fine if you don't want scan
effectiveness.   With bind mounts this becomes trouble quickly.

/tmp
/usr/tmp
/usr/local/tmp

All could be exactly the same physical drive.   Now in the anti-virus
would have to scan each of thoose directories if it does not find out
they are bind mounted.  Also could not look up and say ok that is bind
mounted its fine because since the last lookup a new bind mount could
have been put over the top letting something slip past.

Also TALPA is wrong because its a LSM.   LSM are the most powerful
bits of the OS.   LSM are the enforcers of Linux.  They are the last
line of defence for the OS.   You have your normal permission systems
when they fail then its the job of a LSM to pick up the mess.

Virus scanning is way better inside the permission system.   This way
if you have a issue there is still a back stop of the LSM to prevent a
breached virus scanner doing major system harm.   TALPA risks killing
the backstop.

Basically path based + Linux equals doomed.  VFS is not path based friendly.

Credentials patch on the other hand.  Is under the VFS sees real
partitions so can process divided by partition avoiding rescanning.
Also its in the permission system to has to get approve from the LSM
to do alterations.  So its back stoped.

Also is sitting at exactly the right point to override permissions.

Filesystem cache that exists to sit on top of Credentials provides the
other needed bit scan on write function.

Also filesystem driver level was also correct.  Same reason not messed
up by VFS multi mounting and over mounting.

Don't worry lots of things have been made as LSM's that should not
been.  Basically avoiding having to correct the right things.

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