On 8/6/08, David Collier-Brown <davecb@sun.com> wrote:
quoted text
>
>
> Peter Dolding wrote:
>  > My main issue is TALPA, dazuko and so on of Anti-Virus Filesystem
>> monitoring are all going to break anyhow when
>> http://lwn.net/Articles/251224/ Credentials get added and common
>> filesystem caching gets added.
>>
>> You want to change a permissions on a file/object before its opened.
>> So does the Credential user space daemon on file systems that cannot
>> store secuirty information.  We only really need 1 location in the
>> source base for this.  Expand Credentials slightly to allow anti
>> viruses to operate by by problem.   Even better when FS-Cache can sit
>> on top of Credentials correctly no need for anti virus software to
>> have independent caching of blocked and allowed files.  FS-Cache picks
>> a large amount of this up.
>>
>> Basically TALPA, dazuko and so on of Anti-Virus Filesystem monitoring
>> don't fit in the future design of Linux.   All they will be is
>> duplication of a existing interface.  A interface that complete avoids
>> the stacking issue.
>
> Then in a real sense you've solved much of their problem for them (;-))
> After this comes engineering, so that they can re-use the scanning
> mechanisms they already have, but from a different caller.
>
> The requirements are probably that they know
> - is this an open for read or write (somewhat less time-sensitive)?
> - is the data present, or do we have to wait?
> - if so, for what?
> as of the time they start looking at the file.  Having a race-free
> mechanism using credentials and RCU is, IMHO, A Really Good Thing.
>
> Another thing they and we will likely need is a way to discover
> if a file is inacessable due to an AV operation, and if the time
> it has been inacessable is less than or equal to a scanning
> upper bound by file size or beyond it.  The latter is for repair
> of broken state introduced by the AV process failing.
>
> --dave
>
Failed daemon support has to exist in Credentials for filesystems that
cannot store all the security data and needing third party support.
This is the issue same features basically required to do the same
things.  Different reasons.

One to virus scan.  One to fix up security lacking file systems.  From
what I see exactly the same set of features are needed.

At most only 1 feature is missing a form of copy on write.   Adding
this at credentials level over the complete system would not be a bad
thing.  A option to cache writes for scanning even write to like a
journal for latter applying once scanned.   This could even come as
part of the generic file system cache.

This is why I am kinda scratching my head.   Creating new files also
have to go past Credentials.  Even creating and editing files have to
go past Credentials.

It seams like the best place to look to hook in correctly even better
most of the hook is already there.  Hooking into Credentials is far
better than hooking into syscalls.   Since if a new special feature
filesystem access syscall is added it will still enter Credentials.
On top Credentials interface is under the VFS.  Its between the raw
filesystem and the VFS.   So no more path based errors.

Yes deeper into the OS to the correct location.  Anti-virus methods
are too shallow.  AppArmor and some other secuirty systems like it
have the same path based issue because LSM is too shallow.
Anti-Virus company answer has been to root kit out of the LSM API
wrong answer.  Correct answer is get to the correct location in the
OS.

Note clamfs is on the right path using fuse since this goes under the
VFS and not effected by path issues and is not root kitting the OS.
Of course credentials do the job better.

Really Anti-Virus guys give as a shopping list of exactly what you
need to do.   Key word need.   Hooking syscall's most likely is not a
need but a want.   Even worse a want in the wrong location to give 100
percent coverage.  Ie when a new syscall is added it creates a
backdoor around you scanners.

Peter Dolding

PS I really wound not mind a better paid job.   The developers who
have to created all these incorrect ways have to been paid more than
me.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/