It was <2013-10-16 śro 11:24>, when Carsten Haitzler wrote: > On 10/16/2013 06:11 PM, Łukasz Stelmach wrote: >> It was <2013-10-16 śro 05:42>, when Carsten Haitzler wrote: >>> On 10/16/2013 01:24 AM, Thiago Macieira wrote: >>>> On terça-feira, 15 de outubro de 2013 17:35:13, ?ukasz Stelmach wrote: >>>>>> This is not madness. Before we had dynamic shared libraries we had >>>>>> static shared libraries. No runtime linking required, everything is >>>>>> done via table lookups. You can't delete interfaces from a static >>>>>> shared library, so they make development slightly more difficult. They >>>>>> are lots faster. >>>>> a.out? I may be too young to remember. >>>> Yeah, that's pre-ELF. It's also before my day. My first Linux install >>>> still had >>>> a.out support and libc.so.4, but that was only for compatibility. >>>> >>>> ELF is a big beast, however. To speed up, I recommend prelinking libraries, >>>> executables, using techniques like ELF symbol visibility, protected >>>> visibility, -Bsymbolic, etc. >>> i'm not so sure on prelinking. it does have perf upsides, but comes >>> with downsides. namely ANY change of a shared lib (eg upgrade, >>> security fix etc.) requires re-running prelink on all binaries and >>> other shred libs that depend on it. this is costly and requires a lot >>> of tracking. it also negates the ability to keep md5/sha1 hashes of >>> all files in a "secure place" and compare against it to detect >>> intrusion and hacking... :( >> Could you please, give some more details. What's wrong with keeping >> hashes (sha-256 rather than sha-1 and for ...'s sake not md5) in extended >> attributes. If this is what you mean than what's wrong with offline >> (initramfs) updates running prelink after upgrading? > > normally the hashes are kept as part of the pkging system and are > already computed in my experience. no need to re-read all data and > re-compute. i didn't define where to keep the hashes (normally your > rpm etc. tools keep it in the rpmdb - so u duplicate your rpm db after > any system upgrade off onto read-only storage or offline storage away > from the target system and you then can audit the system by comparing > the computed hashes at that time with the separately stored ones that > the hacker "can't get to and change to match"). > > as we are unlikely to have anywhere to do this on a device that isn't > vulnerable like the fs is, it invariably needs to be done > off-device. so that means private storage "in the cloud" to hold those > hashes or maybe a private server or sd-card etc.
You can keep them anywhere you like as long as you can keep the public key used to sign the list of hashes in a secure place. Hashes without signatures are not very secure. > but much SIMPLER is to simply compare the hashes "now" (compute them) > to the ORIGINAL package contents that was installed/downloaded at > purchase or upgrade time (fetch the file + hash list), but since you > re-write the local binaries, matching to the original hashes isn't > sensible. :) Well, you don't need to hash all sections of ELF (forgive me but I couldn't find which section exactly prelink uses to store its information). -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics
pgpAEctwqPFlC.pgp
Description: PGP signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
