public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
To: snwahofm@mi.uni-erlangen.de,
	Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
Cc: Shawn Starr <spstarr@sh0n.net>, linux-kernel@vger.kernel.org
Subject: Re: Disturbing news..
Date: Thu, 29 Mar 2001 11:10:05 -0600 (CST)	[thread overview]
Message-ID: <200103291710.LAA69167@tomcat.admin.navo.hpc.mil> (raw)

Walter Hofmann <snwahofm@mi.uni-erlangen.de>:
> On Wed, 28 Mar 2001, Jesse Pollard wrote:
[snip]
> > 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.
> 
> So? The virus will just redo the checksum. Sooner or later their will be a
> routine to do this in libbfd and this all reduces to a single additional
> line of code. 

true.

> > That change would even allow for signature checks of the checksum if the
> > signature was stored somewhere else (system binaries/setuid binaries...).
> > But only in a high risk environment. This could even be used for a scanner
> > to detect ANY change to binaries (and fast too - signature check of checksums
> > wouldn't require reading the entire file).
> 
> One sane way to do this is to store the sig on a ro medium and make the
> kernel check the sig of every binary before it is run.

Only for trusted binaries. (extreme paranoia now).
 
> HOWEVER, this means no compilers will work, and you have to delete all
> script languages like perl or python (or make all of them check the
> signature).

Compilers should work normally, the link phase is what would generate
the checksums, though if each object file contained a checksum for the
segment then the interpreters/dynamic loaders would have the choice.

The only applications I see as really needing to check such signatures
are those using PAM. These should do it anyway. The dynamic linking programs
should do so only if they are configured to do so.

> Useless again, IMO.
> 
> > In any case, the problem is limited to one user, even if nothing is done.
> 
> Your best bet is to educate your users.

User eduation is a reasonable substitute as long as they can be directed
to follow the rules.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

             reply	other threads:[~2001-03-29 17:12 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-29 17:10 Jesse Pollard [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-03-28 15:51 Disturbing news 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:40 Jesse Pollard
2001-03-28 15:08 ` Russell King
2001-03-29 12:05 ` Walter Hofmann
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=200103291710.LAA69167@tomcat.admin.navo.hpc.mil \
    --to=pollard@tomcat.admin.navo.hpc.mil \
    --cc=linux-kernel@vger.kernel.org \
    --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