On 2008-07-11T16:12:50, M Harris
I am not saying that there have not been any isolated (even serious) vulnerabilities in the *nix world--- for crying out loud we're not talking about isolated bugs here. I *am* saying that the vulnerabilities *inherent* with windows (name your flavor) do not exist in *nix because of significant design constraints.
I think that's a somewhat dangerous attitude to take. With the prevailence of single user systems, the system is essentially just as toasted if the home directory is destroyed; further, there's a dangerous tendency for people to "cache" the root password, which strikes me as an execeptionally smart time to strike, and some people even recommend setting up sudo for all users without password! It's true that a traditional system setup has difficulty in spreading viruses, but against trojans the system is just as vulnerable; and local root exploits are not that rare, either. That doesn't mean that I consider on-access scanning, implemented via kernel hooks, a smart idea; clearly, scanning on or during transmission (ftp, http, smtp, IMAP etc) is preferable; server-side only is not sufficient for encrypted content though. INotify is neat, but is only delayed; it might be too late, as it needs to happen before the trojan is activated and had a chance to try and disable the local protection layer. AppArmor, DAC, MAC et al are great tools. This doesn't mean that we don't need a general API/ABI which applications - such as Samba, MUA and MTA, browsers et al - can call to have a particular bit of content scanned before proceeding. If you then wanted, you could run an LDD_PRELOAD for apps which don't cooperate and use this to map open()/close() to such functionality. This would approximate the protection you get on Windows with none of the problems of Linux kernel hooks. (Which does not mean this could not be used by an inotify() based scanner as well.) The clear thing though is that on Linux, scanning must happen in user-space. The kernel could possibly cooperate - access denied before the user-space scanner has cleared the file -, but we need something sanner than on-access scanning hooks. Regards, Lars -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org