[lkml]   [2001]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Disturbing news..
    On Wed, 28 Mar 2001, Shawn Starr wrote:
    >Well, why can't the ELF loader module/kernel detect or have some sort of
    >restriction on modifying other/ELF binaries including itself from changing
    >the Entry point?
    >There has to be a way stop this. WHY would anyone want to modify the entry
    >point anyway? (there may be some reasons but I really dont know what).
    >Even if it's user level, this cant affect files with root permissions
    >(unless root is running them or suid).
    >Any idea?

    Sure - very simple. If the execute bit is set on a file, don't allow
    ANY write to the file. This does modify the permission bits slightly
    but I don't think it is an unreasonable thing to have.

    >On Wed, 28 Mar 2001, Matti Aarnio wrote:
    >> 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 <>
    >> > To: <>
    >> > Subject: Disturbing news..
    >> >
    >> >
    >> > 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
    >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    >the body of a message to
    >More majordomo info at
    >Please read the FAQ at
    Jesse I Pollard, II

    Any opinions expressed are solely my own.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:17    [W:0.026 / U:20.616 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site