You can install an antivirus if you want. It should not hurt your machine, but don't expect much protection for your system and don't consider yourself entirely safe. The efficacy of antivirus software is very relative, and they're mostly in use to avoid propagate old malware especially if you have Windows machines in your ecosystem. You should expect a performance decrease, though there are no benchmarks of AV performance on Linux as of today so it can't be quantified.
Why is it that you're not safe with just an antivirus? Because they're only one part of the needed mechanisms. At the moment there are a lot of missing tools for desktop security on Linux. What are the different security mechanisms relevant to desktops?
- Graphic stack security (to prevent keyloggers, clickjacking, screen recording, clipboard sniffing, etc)
- App distribution schemes with security checks (app stores and repositories with static analysis on the apps) and fast security updates
- Malware detection: signature-based (to protect from identified threats) and heuristics-based (or so they say, I've never used any heuristics-based AV and I suspect this is mostly marketing talk to say "we'll throw tons of security warnings at your face when you use a new app")
- Sandboxing (which consists of isolating apps from one another by design)
- Contextual authorisation to use devices and user data with security by designation / user-driven access control / powerboxes / contracts ; requires sandboxing
Currently the only decent thing on Linux is the app security updates, through repositories. All the rest is substandard.
Graphic stack security
We're all relying on the X11 graphical server. X.Org existed for 30 years and the original design is still in use in the server. Back in the day there were no desktop security issues and you won't be surprised to learn that it's not secure at all. You have APIs right out of the box for implementing keyloggers, doing remote code exploitations if the user has any root console open, replacing the session locker to steal passwords, etc, etc.
It's hard to evaluate how Windows 8 and OS X fare on this topic because I could not find any detailed explanations on their graphic stack implementation. Their sandboxed apps have restricted access to most obvious attack vectors but it's really unclear how well designed and implemented this all is. It seems to me that Win 8 forcing Store Apps to run fullscreen and one at a time hides issues in designing a full scale secure window manager. There are lots of issues to take into consideration wrt. window position and sizing, use of transparency and fullscreen, etc. when implementing a window manager with security in mind. I have no idea how OS X does.
Linux will be switching to Wayland in the coming years, which is designed with security in mind. We have a clear model of what capabilities should exist and a general idea of how these will be enforced and how authorisation can be obtained. The main person behind this work is Martin Peres though I happen to be involved in discussing the user and developer experience behind the capabilities. Design and development are ongoing so don't expect anything any time soon. Read this post for more information. Wayland will provide security seamlessly when used in conjunction with app sandboxing.
App distribution
Linux has a system of repositories with various levels of trust, which trained our users to rely only on provided apps and to be wary of proprietary code. This is very good in theory.
In practice I don't know a single distributor that enforces even the most basic security checks on their packaged apps. No static analysis whatsoever for weird system calls, and for anything community it's really not clear whether pre- and post-install scripts (which run as root) are verified at all for obvious bad things.
The security checks done on extensions to GNOME Shell are very light and manual, but at least exist. I don't know about KDE's extensions or other apps.
One area where we shine is that we can pull security updates very fast, usually within a few days for any security flaw. Until recently Microsoft was much slower than that, though they caught up.
Malware detection
The only antivirus software I know on Linux is ClamAV. It seems to me that it only works based on signatures, but then again as you pointed out, we don't have any identified desktop malware to protect against.
There probably are people writing Linux desktop malware in the world of Advanced Persistent Threats. See Mask for an example. It's unlikely that standard AV can do anything against those since APT malware authors are usually talented enough to come up with zero-day exploits.
Now, Microsoft advertises fuzz-testing all of its software for tens of thousands of hours, as opposed to virtually no secure coding practices at all in the Linux ecosystem. From personal experiments with fuzzing I'm absolutely convinced that there are a handful of low-hanging zero-day exploits in some popular Linux software. This will come to hit us on the day we have a financially-viable user base for commonplace malware authors, and then we'll see how good ClamAV turns out to be, but I suspect the app update mechanism will have a bigger impact at dealing with discovered vulnerabilities.
Needless to say both Windows and OS X do significantly better than Linux on this criteria.
Sandboxing and contextual authorisation
Both OS X and Windows 8 provide sandboxing for the apps hosted on their store. I'm not done looking into the quirks of OS X, but Windows 8 Store Apps have very serious limitations in terms of languages and APIs supported, available features and general user experience that can be provided with them. That means unsandboxed desktop apps are here to stay and Microsoft's sandboxing will not protect against malware, only against crafted documents in buggy (Store App) software. OS X seems to do much better though any non-store app is not sandboxed, as well.
Linux has no GUI app sandbox working seamless enough at the moment. We have the underlying confinement technology (the best candidates being Containers based on Linux namespaces, see LXC and Docker, and the next-to-best being MAC enforcement systems that would need to be developed to support some amount of dynamicity). We almost have the IPC and process management mechanisms needed to deploy and handle those sandboxed apps thanks to amazing work on kdbus and systemd. There are a few bits missing, with a few proposals being pushed mostly by the GNOME Foundation (see this video on Sandboxing at GUADEC 13). I'm also involved in discussing how access to data and authorisation can occur but there's no consensus between the few interested people, and design and development take time. It'll probably be a couple more years before decent prototypes exist and before sandboxing is deployed to Linux on any relevant scale.
One of the big issues faced on all platforms is finding out how to authorise apps to get access to data and device capabilities at the right scale. That means, how to let them do what they need to do without pestering users with authorisation prompts whilst preventing apps from abusing privileges. There are serious loopholes in how Windows 8 lets Store Apps handle recent documents and apps' futureAccessList. At this stage securing document access further without aggravating the cost of security for developers and users is an open question, which a bunch of people happen to be working on as well :)
