Cc: Theodore Tso <tytso@...>, Arjan van de Ven <arjan@...>, <rmeijer@...>, Alan Cox <alan@...>, <capibara@...>, Eric Paris <eparis@...>, Rik van Riel <riel@...>, <davecb@...>, <linux-security-module@...>, Adrian Bunk <bunk@...>, Mihai Don??u <mdontu@...>, <linux-kernel@...>, <malware-list@...>, Pavel Machek <pavel@...>
unless you have a signed file of hashses of the filesystem, and you check
that all the hashes are the same, you have no way of knowing if the
filesystem was modified by any other system.
you may be able to detect if OS Y mounted and modified it via notmal
rules of that OS, but you have no way to know that someone didn't plug the
drive into an embeded system that spit raw writes out to the drive to just
modify a single block of data.
this is a policy decision that different people will answer differently.
put the decision in userspace. if the user/tool thinks that these things
require a re-scan then they can change the generation number and
everything will get re-scanned. if not don't change it.
if you want to trust another system to do the scanning for you the
userspace code needs to work out a way to use the same generation number
of the different machines.
the underlying mechanism can work in all of these cases. which one you
choose to use is up to you, and it doesn't matter what you choose, the
mechanism allows other people to make different choices.
the mechanism I outlined will work just fine for a whitelist scanner. the
user can configure it as the first scanner in the stack and to trust it's
approval completely, and due to the stackable design, you can have thigns
that fall through the whitelist examined by other software (or blocked, or
the scanning software can move/delete/change permissions/etc, whatever you
configure it to do)
forget the speed of the machines, if you have a tens of TB array can will
take several days to scan using the full IO bandwith of the system (so
even longer as a background task), you already can't afford to scan
everything every update on every system.
however, you may not need to. if a small enough set of files are accessed
(and you are willing to pay the penalty on the first access of each file)
you can configure your system to only do on-access scanning. or you can
choose to do your updates less frequently (which may be appropriate for
your environment)
you are arguing with the wrong people here. we are not trying to define
the future of anti-virus technologies, we are trying to figure out how to
provide the hooks so that people and companies can go off and do the
research and experimentation and try different approaches.
the threat model we have been trying to deal with has not included trying
to scan a drive that will be accessed by another OS to make sure that the
other OS won't have any problem with it. I'm not sure thats even possible
(it's like network IDS where you can't just look at the packet fragments,
you need to duplicate the logic of the destination OS for how those
fragments are reassembled, when the source isn't available for the target,
this is reduced to 'best effort')
if you think we should be trying to deal with a different threat model,
say so and argue threat model vs threat model. you may be right that the
threat model isn't appropriate and needs to change, but arguing that the
proposed solutions don't satisfy your threat model without documenting
what that is doesn't get us anywhere.
David Lang
--
