Karl J. Runge said:
> On Wed, 28 Mar 2001, Jeffry Smith <[EMAIL PROTECTED]> wrote:
> > Even more, from the discussion I've seen (including by some folks who have
> > found the source code), this only affects BINARIES that are writable. So,
> > if you store binaries in your home directory, or in /home, or in /, for
> > which you have write permission (why anyone would make a binary writable,
> > I don't know), it can affect it. If you give the binary r-x permission
> > only, virus stopped. Scripts don't appear to be affected.
> ...
> > 3. Don't make binaries writable unless you can come up with a very good
> > reason.
>
> I might be missing something about what you are implying here, but
> couldn't a virus (not this demo one) simply do a chmod(2) on the binary
> to make it writable if it wanted to? (if the user owned the file and
> there was enough space in the virus' code)
Yes, they can do a chmod(2) for binaries you own. But, by not making all
binaries writable, you're protected from the virus infecting binaries you
don't own.
>
> Or are you saying just *this* particular demo virus will be thwarted by
> chmod a-w? If so, I wouldn't call it that important a general rule to
> chmod a-w all of your binaries. (but it does help a little I guess...)
chmod (as root) all binaries to be non-writable for user/group/other, and
you're at least safe from infection of non-owned binaries. However, it
also protects binaries you own for THIS virus.
>
> Of course, viruses (sp?) concerns aside, it is a potentially bad idea
> to have a binary writable by group or other!!! No system executables
> would/should ever have that setting. Users with a poor umask setting
> (e.g. 000) building programs will be vulnerable to bad local users as
> well as getting viruses from other users.
yep. Basic security precautions protect you for most viruses on Linux.
jeff
-----------------------------------------------------------------------
Jeffry Smith Technical Sales Consultant Mission Critical Linux
[EMAIL PROTECTED] phone:603.930.9739 fax:978.446.9470
-----------------------------------------------------------------------
Thought for today: creep v.
To advance, grow, or multiply inexorably. In
hackish usage this verb has overtones of menace and silliness,
evoking the creeping horrors of low-budget monster movies.
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
