From: "Les Mikesell" <lesmikesell@xxxxxxxxx>
Do you understand how AV software functions? One mode checks file signatures for known virus signatures and prevents them from running.I know how it's supposed to function - and in the places it is really needed you can't afford the overhead.
Boy howdy that can be true. Playing games is NOT such a "place". Putting video out a set of SDI ports in a broadcast studio IS such a place. I have recommended to my customer that he recommend to his customers that they isolate their video machines to the maximum extent possible with suitable firewall and AV protection on the other machines the active video machines touch. I already have had to trim capabilities we wanted as I blow the both the various data busses in the system as well as the dual dualcore 3 GHz Intel based motherboards. (There is something impressive to watching all four CPUs top out in task manager and know it is from real computing load not from a stupid explorer lockup. Did I ever say I hate Windows here? If not consider it said.)
The cycle from discovering a virus to developing a signature for catching it is MUCH faster than the usual bug report or even security bug report to update cycle. Your period of vulnerability is reduced. That is "a good thing." (tm)That hasn't been my experience. I've been through 2 zero-day Windows exploits where we were the first to report the offending file to two popular AV companies that we used plus clam. One wasn't that bad and I've forgotten the details. The other one was something that blasted the network to a point where a few infected PCs would overload 100M router interfaces making both the primary and failover routers try to become active. It wasn't fun and it was 3 days before either commercial vendor responded with a new signature from the file we sent them and 5 for clam. By contrast it is rare for a critical remote vulnerability to be known for more than 3 days in Linux distributions without having the update to fix it released.
Not as rare as all that. The folks involved, kernel, gnome, kde, OO, or
others, have to be informed. The person responsible then has to be woken
up from the grave or wherever else he's been hiding. A fix needs to be
generated AND validated against the software suite involved and the
items that depend on it. THEN the distros get it. In Red Hat's case with
Ingo and others on their staff, it's pretty quick. How quick is Debian?
How quick is "k12ltsp"? Each step through the chain has its own validation
process to avoid the "recalled patch" situation Microsoft suffered quite
recently. Three days would be par for some kinds of patches, say an
overrun or the like. But other problems still, in theory, exist in the
kernel today. (Their explotation is so difficult that they're not
considered to be a real problem by anyone but perhaps NSA.)
ONE reason Linux is MORE secure than Windows is the multiple eyes. I like
that. I wish I had eyes looking over my code more often. (But then I'd
have to retire and do the coding on retirement income. I'd lose my income
if I had to produce for open source. One sale and it's "gone." And in
fact it might be gone before I could sell one.)
Another reason Linux appears more secure than windows is market share.
Windows is a far more profitable target to exploit. To start with they
are inevitably sloppier because they opt for user experience rather than
security and have fewer eyes on the code. When Linux is attacked with
the same level of intensity as Windows it gets cracked. This isn't as
easy. But it is done. Otherwise, why bother with RKHunter or chkrootkit?
More secure is not absolutely secure. If I make more layers for the
critter to wriggle through I have a better chance of noticing it and
doing something about it. Hence, the root of this thread. I like the
features in iptables because I can tailor defense to make penetration
MUCH harder at the expense of only a slight impediment to access. That
is a really good thing in my book. That is why I passed the rules along
in the spirit by which I was clued in on a RedHat list some time ago.
{^_-}
Yes, you need to keep up with the updates. What's "too many" daemons? The point of having a computer is the services and often the remote access it provides.If you do not need a web server on your desktop do not install it let alone run it. If you need to run it (for documentation) limit its access from off the machine. If you must access it remotely don't enable scripting facilities. And so forth. If you do not need to run smtpd on your machine, then don't. If you do not need to run a POP3 tool on your machine, then don't.But I do need all of those things (and imap and http too). Not all of them on all machines, but if it isn't vulnerable in the places I need it, then it won't be other places either. The great thing about free software is that when someone gets it right, it doesn't matter how many copies of it you run. And if it is vulnerable, I want it reported and fixed, not just avoided so the machine where I need it will be the first to be exploited.Worse yet if you don't need to run a geewizzilator daemon on your system, then don't. (That is to say a "gee I wonder what's that" daemon.)Same there - if there is a vulnerability, find it and fix it and it won't matter how many of them people run.There may be undiscovered bugs in Linux distros, but as they are discovered there is no excuse for not fixing them in the product itself. What possible good can come from a third party product (just as likely to contain even more unknown vulnerabilities) being used as a band-aid solution instead of just fixing issues as they are discovered? And that applies to all services - someone needs to run them and they should not make their system any easier to crack beyond adding passwords that might be guessed.How many different "products" exist in the Red Hat and Fedora Core Linux distributions?A lot - but I'm not sure that's a relevant question. If they have bugs they need to be found and fixed.-- Les Mikesell lesmikesell@xxxxxxxxx -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
