Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon access scanning

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Theodore Tso <tytso@...>, Peter Dolding <oiaohm@...>, Arjan van de Ven <arjan@...>, <david@...>, <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@...>
Date: Sunday, August 17, 2008 - 3:49 am

On Sun, Aug 17, 2008 at 1:17 AM, Theodore Tso <tytso@mit.edu> wrote:
I am not saying in that it has to be displayed in the normal VFS.  I
am saying provide way to see everything the driver can to the
scanner/HIDS.   Desktop users could find it useful to see what the
real permissions are on disk surface useful for when they are
transferring disks between systems.  HIDS will find it useful for Max
confirm that nothing has been touched since last scan.   White list
scanning finds it useful because they can be sure nothing was missed.

You mentioned the other reason why you want to be under the vfs.   As
you just said every time you mount a file system you have to presume
that its dirty.  What about remount?   Presume its all dirty just
because user changed a option to the filesystem?  Or do we locate
ourself in a location that remount don't equal starting over from
scratch.   Location in the inodes wrong for max effectiveness.   Even
on snapshoting file systems when you change snapshot displayed not
every file has changed.   The Linux File System Driver interface needs
to change.   Sorting out this section of the file system driver
section also would allow like a ISO or UDF to be multi mounted with
different filter options to the vfs.   Reason driver goes up to a
central point then to the vfs so filters that hide files and
permissions could be turned on and off at bind mounts.  The alteration
to make AV work perfectly opens up way more doors.  Including file
system neutral mount filters so that users and group id's on a file
system can be mapped to local user and group id's.  UUID on the
partition could be used to track remove able disks using it.  500 user
on current system might be acting as 1000 user on a remote/removable
disk since the users id on that system that disk owns to is 1000.

Also you are not thinking real world.   Most common reason to be
scanning read only disks on one machine then using it on another not
fully setup is the restoring stage from backups.   This is where you
all ready know what the virus is.   So that the signatures have been
update for viruses created in the last hour  really normally does not
matter for backups a week old.

It is critical for sorting out infected from non infected disks that
scanning for that is fool proof as possible.  Worst nightmare is to
complete a reinstall after a really destructive virus only to have it
do its destruction again.

Logic that scanning will always be needed again due to signatures
needing updates every few hours is foolish.   Please note signatures
updating massively only apply to black list scanning like
anti-viruses.   If I am running white list scanning on those disks
redoing it is not that required unless disk has changed or defect
found in the white list scanning system.  The cases that a white list
system needs updating is far more limited:  New file formats,   New
software,  New approved parts or defect in scanner itself.
Virus/Malware writer creating a new bit of malware really does not
count if the malware fails the white list.  Far less chasing.  100
percent coverage against unknown viruses is possible if you are
prepared to live with the limitations of white list.   There are quite
a few places where the limitations of white list is not a major
problem.

So don't use the idea of the black list flaw against me.   It does not
have to exist we should go after 100 percent scanning since we can go
after white list scanning that can provide 100 percent coverage with
its other issue of blocking some things it should not.  Viruses and
Malware that users themselfs don't install or approve don't even get a
chance against white list scanning.

UAC for Linux are like the selinux systems.  UAC fails against malware
too many windows users get use to clicking yes way too often.  Defect
on the LSM side we must not copy.

Anti-Virus companies are going to have to lift there game stop just
chasing viruses because soon or latter the black list is going to get
that long that its going to be unable to be processed quickly.
Particularly with Linux's still running on 1.5 ghz or smaller
machines.  Instead swap across to the shorter white list to process
and sort.   Quarantining for black list scanning so performance of
machine is hit with the least ammount.   Some areas like email, p2p
for people using formats that should not contain macros or executable
code white list scanning there is all that is needed before either
blocking or asking user if black list scanning should be preformed or
the file just deleted.   Lets close the door's on these malware
writers without hurt end users any more than we have to.  What is the
point of running a full black list across a file the user will delete
because it was not what they thought it was.

Peter Dolding
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfac..., David Collier-Brown, (Sun Aug 17, 5:17 pm)
Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfac..., Arjan van de Ven, (Sat Aug 16, 12:09 am)
Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfac..., Peter Dolding, (Sun Aug 17, 3:49 am)