From: Russell King <rmk@arm.linux.org.uk>
To: Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
Cc: snwahofm@mi.uni-erlangen.de,
Jesse Pollard <jesse@cats-chateau.net>,
Shawn Starr <spstarr@sh0n.net>,
linux-kernel@vger.kernel.org
Subject: Re: Disturbing news..
Date: Wed, 28 Mar 2001 16:08:25 +0100 [thread overview]
Message-ID: <20010328160825.C6867@flint.arm.linux.org.uk> (raw)
In-Reply-To: <200103281440.IAA48398@tomcat.admin.navo.hpc.mil>; from pollard@tomcat.admin.navo.hpc.mil on Wed, Mar 28, 2001 at 08:40:42AM -0600
On Wed, Mar 28, 2001 at 08:40:42AM -0600, Jesse Pollard wrote:
> Now, if ELF were to be modified, I'd just add a segment checksum
> for each segment, then put the checksum in the ELF header as well as
> in the/a segment header just to make things harder. At exec time a checksum
> verify could (expensive) be done on each segment. A reduced level could be
> done only on the data segment or text segment. This would at least force
> the virus to completly read the file to regenerate the checksum.
Checksums don't help that much - virus writers would treat it as "part
of the set of alterations that need to be made" and then the checksum
becomes zero protection.
Your system binaries are safe from the virus (from my understanding of the
poor writeup) if you are sensible about your system - ie, don't run stuff
as the root user, don't login as root, ensure that your binaries are owned
by root etc.
If users have their own binaries, then they should take adequate care
over them (find ~ -type f -perm +111 | xargs chmod a-w) to ensure that
they are not writable (this applies to your argument as well).
Once you're in this situation:
1. Users can't write to their executables without first chmod'ing them.
(won't take long for a virus writer to get the idea that they should
chmod +w them first).
2. If a user binary becomes infected, only people able to run that binary
also become infected. Certainly root should under no circumstances
run any program which a user has compiled - the user may have some
nice code in there which creates another root user in /etc/passwd
with no password entry.
3. Since you're only running system programs as root (and by that I mean
stuff for administration, not stuff like mail clients, news readers
etc), your system binaries should not become infected.
Therefore, if you follow good easy system administration techniques, then
you end up minimising the risk of getting:
1. viruses
2. trojans
3. malicious users
cracking your system. If you don't follow these techniques, then you're
asking for lots of trouble, and no amount of checksumming/signing/etc
will ever save you.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
next prev parent reply other threads:[~2001-03-28 15:22 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-28 14:40 Disturbing news Jesse Pollard
2001-03-28 15:08 ` Russell King [this message]
2001-03-29 12:05 ` Walter Hofmann
-- strict thread matches above, loose matches on Subject: below --
2001-03-29 17:10 Jesse Pollard
2001-03-28 15:51 Jesse Pollard
2001-03-28 15:54 ` rmk
2001-03-28 21:19 ` Gerhard Mack
2001-03-28 15:43 Jesse Pollard
2001-03-28 15:31 Jesse Pollard
2001-03-28 14:43 Jesse Pollard
2001-03-28 14:15 Jesse Pollard
2001-03-28 14:53 ` Russell King
2001-03-28 5:52 Ideas for the oom problem Jonathan Morton
2001-03-28 6:16 ` Disturbing news Shawn Starr
2001-03-28 7:19 ` Matti Aarnio
2001-03-28 7:27 ` Shawn Starr
2001-03-28 12:08 ` Jesse Pollard
2001-03-28 5:50 ` Ben Ford
2001-03-28 12:50 ` Walter Hofmann
2001-03-28 14:04 ` Simon Williams
2001-03-28 15:04 ` Olivier Galibert
2001-03-28 15:49 ` Simon Williams
2001-03-28 11:57 ` Ben Ford
2001-03-29 8:02 ` Helge Hafting
2001-03-28 17:51 ` Olivier Galibert
2001-03-28 12:53 ` Keith Owens
2001-03-28 13:00 ` Russell King
2001-03-28 14:10 ` Sean Hunter
2001-03-28 15:36 ` john slee
2001-03-28 16:18 ` Jonathan Lundell
2001-04-02 23:10 ` Dr. Kelsey Hudson
2001-03-28 17:29 ` Horst von Brand
2001-03-28 10:00 ` Helge Hafting
2001-03-28 13:25 ` Alexander Viro
2001-03-28 14:32 ` Romano Giannetti
2001-03-28 14:57 ` Bill Rugolsky Jr.
2001-03-28 14:57 ` Alexander Viro
2001-03-28 16:14 ` Romano Giannetti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010328160825.C6867@flint.arm.linux.org.uk \
--to=rmk@arm.linux.org.uk \
--cc=jesse@cats-chateau.net \
--cc=linux-kernel@vger.kernel.org \
--cc=pollard@tomcat.admin.navo.hpc.mil \
--cc=snwahofm@mi.uni-erlangen.de \
--cc=spstarr@sh0n.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox