[linux-elitists] random questions
Fri Dec 7 20:42:45 PST 2001
On Thu, Dec 06, 2001 at 10:28:30AM -0800, Don Marti wrote:
> How many damn "The Linux viruses are coming! Virus checkers
> are still relevant!" articles are we going to have to read
> until even the Mainstream Media starts ignoring the anti-virus
> vendors? (Rick Moen explains the UNIX/Linux security model and its
> virus-resistance in this article:
Rick's page presents _an_ explanation, but I don't think it has much
relevance to the real reason why current viruses don't present as much
of a threat to Linux as they do to Windows. It worries me that people
lean a lot on "users can't write system files" arguments; to me they don't
capture the essential reasons Linux is more robust against virus attacks.
It's especially worrisome given that someone could yet come along (in
fact, I expect it to happen) and create an environment which allows
Microsoft-style viruses to propagate. We need to know exactly which
implicit policies keep Linux virus-free so that we can land on clueless
violators like a bag of anvils.
The whole argument "users can't affect system files, only root can
do that; be careful in your root shells" doesn't seem relevant to the
type of viruses that have made the headlines in the last year or two.
All of these viruses have propagated either by Visual Basic macros in
Microsoft Office documents, or by various tricks that convince you to
run executables from your mailer [I'm excluding fully automated worms
from discussion, as even on Windows they are better prevented by firewall
software and by just not running unnecessary daemons than by anti-virus
Question: How much would these viruses have been hindered by a strict
user/system file separation? Answer: Not at all. None of the things
these viruses do require root privilege: not propagation via mail, not
listening on open ports, not snarfing addresses from your address book,
and not deleting your precious files (I don't know about the rest of you,
but on my systems most of the stuff a virus is prevented from deleting
comes from Debian servers anyway). The root privilege argument seems
more relevant to the days of DOS, floppy-net, and binary .com viruses.
I barely remember what a floppy looks like, and I wouldn't remember
that people ever exchanged files on physical media unless Hollywood kept
So what are the real causes of Linux's greater security?
First, but uninterestingly, there's market saturation. You couldn't
get a massive-scale Outlook-style virus going on Linux right now since
you don't have enough of a Linux/standard mailer/standard address book
desktop monoculture. But let's assume Linux starts picking up swarms of
new users--more than mailer-virus critical mass--and they all standardize
on, say, Evolution. So I'll ignore the user numbers for now.
There's also a lack of office software with insecure macro facilities.
Since MS Office has so conspicuously failed in this arena for so long,
I hope that by the time Linux desktop office software really Gets There
(I'm personally using the metric: "Can I run a complete, full-featured
office suite which natively uses the same widgets and conventions as
the rest of my desktop?" :-), this problem will never have been given
a chance to arise.
I think the really interesting cause is that Linux has always done
software distribution out-of-band, where in-band is defined as a
typical desktop user's daily routine: sending and receiving email,
reviewing and editing documents, and browsing the Web. There's never
been an assumption that you would install binary software as yourself.
You're certainly _allowed_ to install and run any software you want
under ~, though, which is why the I don't find the "never run untrusted
binaries as root" argument convincing (it's good advice, but it doesn't
explain why viruses don't work well on Linux).
But the general assumption of out-of-band installation creates an
environment which is inimical to viruses:
-- There's no such thing as a self-installing executable (I would love
to see a distribution which packages everything in shar files, just
to see the horrified reaction :-). Self-installing executables are
a convenience which provide tighter integration into the familiar
-- There is no way to install software straight from a link on the
Web. Again, the ability to do so is a convenience for "in-band"
-- For many reasons, people don't email programs to one another. If
I want to tell someone about a program, I'll probably just mention
its name, assuming my correspondent can find the distribution
package. Maybe I'll include a download URL for the source tarball.
-- No file distribution tools (mailers, Web browsers) save downloaded
or distributed files in executable form (+x).
-- You don't even have any writeable directories in your $PATH unless
you explicitly put them there.
In short, it would be perfectly possible given Linux's security model to
write a package manager designed to install per-user software packages in
home directories, and to create mailers, file managers, and Web browsers
which would install these packages (including running scripts) for you
with a single click. For extra points, obscure the filename in the
UI and allow the package to choose its own icon. If that were done,
Linux would become as insecure against certain threats as Windows.
Another way of characterizing this form of virus security is that it
comes not from the user/root distinction, but from a careful distinction
between code and data even within a single privilege domain. Windows has
near-zero separation between code and data: office documents can contain
both interchangably, and when you click on a URL or local file icon you
can't even tell in advance whether the system will interpret the referent
of your click as code or as data.
As Linux becomes more accessible to new users and acquires more GUI
tools, the permeability of these code/data barriers will increase.
IMHO this is what we should all be watching for on the security front.
I'm not advocating that we maintain artificial "busy work" barriers like
compilation from source or ability to handle a bash shell, but we should
keep a close eye on people designing GUIs which straddle the code/data
barrier, to ensure that they make intelligent choices with these security
issues in mind rather than pick up all their cues from insecure systems
P.S. Any of you know xauth well enough to describe a secure setup for
running your web browser under a different user ID for security reasons?
I can do 'ssh -X miket2@localhost' but I'd like a direct X connection
instead of a slower ssh-encapsulated one.
More information about the linux-elitists