mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Matti Aarnio <matti.aarnio@zmailer.org>
To: Shawn Starr <spstarr@sh0n.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Disturbing news..
Date: Wed, 28 Mar 2001 10:19:10 +0300	[thread overview]
Message-ID: <20010328101910.D23336@mea-ext.zmailer.org> (raw)
In-Reply-To: <Pine.LNX.4.30.0103280115180.7637-100000@coredump.sh0n.net>; from spstarr@sh0n.net on Wed, Mar 28, 2001 at 01:16:02AM -0500

On Wed, Mar 28, 2001 at 01:16:02AM -0500, Shawn Starr wrote:
> Date:	Wed, 28 Mar 2001 01:16:02 -0500 (EST)
> From:	Shawn Starr <spstarr@sh0n.net>
> To:	<linux-kernel@vger.kernel.org>
> Subject: Disturbing news..
> 
> http://news.cnet.com/news/0-1003-200-5329436.html?tag=lh
> Isn't it time to change the ELF format to stop this crap?
> Shawn.

	Why ?   "Double-click on attachment to run it" is typical
		M$ client stupidity -- and the reason why there
		are so many things that can mail themselves around.

	Changeing ELF-format would be comparable to what M$ did when
	they met the first Word macro viruses -- they changed the
	script language inside the Word...   What good did that do ?
	Did it harm people ?  You bet...


	You are downloading binaries off the net, and not compiling
	from the sources ?  (Yes, we all do that.  This is why folks
	these days carry PGP signatures at the RPM packages.)


	So, the program modifies ELF format executables by rewriting
	some instructions in the beginning (propably to map-in the virus
	code proper with X-bit on), and tags itself (PIC presumably) at
	the end of the file.



	Another issue is "safe conduct" practice of installing binaries
	with minimum privileges (ok, granted that for e.g. RPMs that
	usually means root), and *never* running them with undue levels
	of privileges -- not even as the owner of said executables.



	Ok, granted that we have dangers of getting arbitrary BAD programs
	into our systems, how can we combat that ?   Virus-scanners
	(as much good as they could do..) don't really work in UNIX
	environments where "small things" like intercept of every
	exec(), and open() via privileged program (scanner) is not
	available feature. (I think doing it by passing a AF_UNIX
	message with fd + flags to registered server, expecting answer
	for the open() -- this would happen *after* the file open is
	done with user privileges, but before the call returns.)
	(Trapping open() so that shared-libraries could be scanned.)

	There could be, I think, a method for doing such intercepts,
	which could be used by security scanners to implement some
	sense of security in Linux-like systems.

	Is it good enough, e.g. when some file is multiply-mapped to
	shared programs, and application rewrites parts of the file ?
	Can it detect that kind of multi-mapped writing-sharing ?

	Can such system be made fast ?  (Scanner becomes performance
	bottle-neck.)


	How about PROPER Orange Book B-level security ?
	E.g. NSA trusted-linux ?


/Matti Aarnio

  parent reply	other threads:[~2001-03-28  7:20 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-27 21:29 [PATCH] mm/memory.c, 2.4.1 : memory leak with swap cache (updated) Richard Jerrell
2001-03-27 21:18 ` Rik van Riel
2001-03-27 23:10   ` Richard Jerrell
2001-03-27 22:57     ` Rik van Riel
2001-03-28  0:53   ` Ideas for the oom problem james
2001-03-28  0:52     ` Rik van Riel
2001-03-28  1:14       ` Doug Ledford
2001-03-28  3:21         ` Rik van Riel
2001-03-28  3:41           ` Doug Ledford
2001-03-28  3:53             ` Rik van Riel
2001-03-28  1:39       ` james
2001-03-28  5:52     ` Jonathan Morton
2001-03-28  6:16       ` Disturbing news Shawn Starr
2001-03-28  6:33         ` Disturbing news.. Idea Shawn Starr
2001-04-21  0:43           ` Serious Latency problems : 2.4.4-pre5 Shawn Starr
2001-03-28  7:19         ` Matti Aarnio [this message]
2001-03-28  7:27           ` Disturbing news 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
2001-03-28 14:38     ` Ideas for the oom problem Hacksaw
2001-03-28 15:56       ` Andreas Rogge
2001-03-28 23:33         ` Hacksaw
2001-03-28 23:47           ` Tim Haynes
2001-03-29  0:12             ` Hacksaw
2001-03-27 21:51 ` [PATCH] mm/memory.c, 2.4.1 : memory leak with swap cache (updated) Linus Torvalds
2001-03-28 14:15 Disturbing news Jesse Pollard
2001-03-28 14:53 ` Russell King
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:43 Jesse Pollard
2001-03-28 15:31 Jesse Pollard
2001-03-28 15:43 Jesse Pollard
2001-03-28 15:51 Jesse Pollard
2001-03-28 15:54 ` rmk
2001-03-28 21:19   ` Gerhard Mack
2001-03-29 17:10 Jesse Pollard

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=20010328101910.D23336@mea-ext.zmailer.org \
    --to=matti.aarnio@zmailer.org \
    --cc=linux-kernel@vger.kernel.org \
    --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

all inboxes | Powered by JetHome®