[opensuse] Re: A BIG "show stopper" for openSUSE at the corporate level anyway!!
On Wed, 09 Jul 2008 10:52:47 -0500, Sunny wrote:
On Wed, Jul 9, 2008 at 10:17 AM, Jim Henderson
wrote: Which is great until that backup fails. I don't know how much data you've got, but if I ran two backups of all the computers in my house, I'd probably need a couple of TB drives. I archive my DVDs and CDs and that takes a *lot* of space.
I do not consider ripped DVDs and CD "critical". Unless you are not doing anything unlawful, you still have the original - better than any backup :)
Yes, I agree. My point is that if I were to use a backup procedure, I'd need lots of space.
And, for that matter, such a data is not accessed regulary, and will not suffer if they are placed on a RAID5 volume.
Ah, yes, so now we're up to buying a RAID-5 solution rather than implementing an on-demand virus scanner. I suppose I could also build a multi-million dollar cluster so we don't need on-demand scanning as well. Buy a couple of T1s *for my home* and do an off-site redundant cluster? Where does the silliness end here?
It's good you can afford the time and the hardware to do this. Many home users can't. Do you really think people who are buying OLPC PCs are going to have the resources available to buy another hard drive or two for backup purposes?
Do you really think that OLPC will be able to perform "any" useful work, if it has on-access file scan enabled?
I think it could, if the on-access scanning is implemented properly. I've used on-access scanning on Windows and while it does impact performance, it certainly didn't make the system unusuable. It certainly was more usable than while doing a full system scan for viruses.
It's hard to say, but it seems to me it makes sense to prepare for that possibility - far less sense to have people go "oh crap, it *is* susceptible after all" once the desktop becomes popular enough to be a target.
As mentioned before - the only way an executable may appear on a user's computer, and run therefor, is if the user put it there, and change the execution permission. So, in order to file to appear on the computer - it have to be downloaded (the browser may invoke AV after download), received by email (on demand scan when message arrives), or copied over from another medium - in such a case manual scan will be enough.
That resolves any issue with executable viruses. OK, so how about macro viruses? Users are NOT going to manually scan individual files every time they use them. Do you?
Only the last case may kind of "require" on-access scan, as people are lazy.
Welcome to the world of non-technical users.
And still there is possibility to use another means, like monitoring a directory for changes, and scan on write, not on read.
*Bingo*. There are other means, and there's no reason you couldn't monitor for changes and scan on read (or make it an option to do so).
And if somebody is stupid enough to run an executable out of removable media (usb stick) w/o checking it - you know, one can never "outsmart" the creative stupidity. You can not even prevent any user to delete his own files by "mistake".
Sure, but that doesn't mean that you make it as easy as possible for them to make a mistake that compromises the system.
Anyway, I think that this thread should end already. Obviously the discussion should not happen here, but on a kernel developer's list, as this is the kernel devs that decided to not implement on-access scan in the kernel in the first place.
I could've sworn there was a hook of some sort for file change monitoring. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2008-07-09 at 16:12 -0000, Jim Henderson wrote:
As mentioned before - the only way an executable may appear on a user's computer, and run therefor, is if the user put it there, and change the execution permission. So, in order to file to appear on the computer - it have to be downloaded (the browser may invoke AV after download), received by email (on demand scan when message arrives), or copied over from another medium - in such a case manual scan will be enough.
That resolves any issue with executable viruses. OK, so how about macro viruses?
Samething. Scan on download. Or have scan on load on the program executing the macro. I certainly do not want scan on read on every single file in my system. Not in Linux. That's one of the reasons I use Linux: I do not need it. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIdPzRtTMYHG2NR9URAshRAJ9dpGOI9ez9bORfGZ2Bts371kSP9ACfQYzY fpDa4OlMHKkOdCbIqZbXvKM= =hXw/ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, 09 Jul 2008 20:00:47 +0200, Carlos E. R. wrote:
That resolves any issue with executable viruses. OK, so how about macro viruses?
Samething. Scan on download. Or have scan on load on the program executing the macro.
Yeah, so an extra layer in the application rather than have it done one way at the OS level. I can't see that making sense - it's like saying "every download manager ever created must have built-in virus scanning". Why reinvent the wheel in each application? I thought one of the benefits of using *nix systems in general was that things tend to be built on special-purpose components. Like Mandvd, it doesn't reimplement ffmpeg/mplayer/transcode, it calls them. It doesn't implement its own DVD authoring suite, it uses dvdauthor. The whole idea of most application development in Linux seems to me to be code reuse and not making every application implement its own way of doing things. I'm just really puzzled by this attitude that each application should implement its own virus scanning - that seems so antithetical to the whole idea of how programs are developed on the platform.
I certainly do not want scan on read on every single file in my system. Not in Linux. That's one of the reasons I use Linux: I do not need it.
Well, sure, that's also a reason I use Linux. But you and I are *smart* users. Not all users have our saavy. As the Linux user base grows, the average level of expertise the user has is going to drop farther and farther. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thu, 10 Jul 2008 03:40:25 Jim Henderson wrote:
On Wed, 09 Jul 2008 20:00:47 +0200, Carlos E. R. wrote:
That resolves any issue with executable viruses. OK, so how about macro viruses?
Samething. Scan on download. Or have scan on load on the program executing the macro.
Yeah, so an extra layer in the application rather than have it done one way at the OS level. I can't see that making sense - it's like saying "every download manager ever created must have built-in virus scanning". Why reinvent the wheel in each application? I thought one of the benefits of using *nix systems in general was that things tend to be built on special-purpose components. Like Mandvd, it doesn't reimplement ffmpeg/mplayer/transcode, it calls them. It doesn't implement its own DVD authoring suite, it uses dvdauthor.
And applications that need to scan for macro viruses on loading a file can call the already-installed av program. As someone said - why reinvent the wheel?
The whole idea of most application development in Linux seems to me to be code reuse and not making every application implement its own way of doing things.
I'm just really puzzled by this attitude that each application should implement its own virus scanning - that seems so antithetical to the whole idea of how programs are developed on the platform.
And it is. No-one suggested that each application should reimplement their own scheme. Crossover Linux is a case in point; I have MS Office installed on my machine for compatibility purposes (mainly for my wife, although I have some Excel spreadsheets that I need 100% macro compatibility for), running under Crossover. Each time Word or Excel open a document, they request a virus scan. Crossover calls clamav (or clamd, one of the two) and scans the file, just like what happens on Windoze XP/Office XP when I open a file there; in that case it calls AVG.
I certainly do not want scan on read on every single file in my system. Not in Linux. That's one of the reasons I use Linux: I do not need it.
Well, sure, that's also a reason I use Linux. But you and I are *smart* users. Not all users have our saavy. As the Linux user base grows, the average level of expertise the user has is going to drop farther and farther.
Yes, but the basic premise remains true. In order to do damage to the *system*, a virus has to execute as *root*. That can happen if a user is logged in as root and runs an infected program, or if a binary is somehow run setuid. Incidentally, tripwire was pretty good at detecting modified files, once it had built its initial database which did take some time. I believe it is no longer open source? I haven't heard about it for a while... Rodney. -- =================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au =================================================== Electricity is actually made up of extremely tiny particles, called electrons, that you cannot see with the naked eye unless you have been drinking. Electrons travel at the speed of light, which in most American homes is 110 volts per hour. This is very fast. In the time it has taken you to read this sentence so far, an electron could have traveled all the way from San Francisco to Hackensack, New Jersey, although God alone knows why it would want to. The five main kinds of electricity are alternating current, direct current, lightning, static, and European. Most American homes have alternating current, which means that the electricity goes in one direction for a while, then goes in the other direction. This prevents harmful electron buildup in the wires. -- Dave Barry, "The Taming of the Screw"
participants (3)
-
Carlos E. R.
-
Jim Henderson
-
Rodney Baker