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 --
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| Heiko Carstens | Re: -mm merge plans for 2.6.23 -- sys_fallocate |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | Re: [GIT]: Networking |
| Jarek Poplawski | [PATCH iproute2] Re: HTB accuracy for high speed |
