On 10/16/2013 07:56 PM, Łukasz Stelmach wrote:
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.
and where will you keep the key?
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).
prelink locks down the address relocations from memory of symbols - this
disallows them from moving at runtime. problem is.. if u don't hash that
you have just left a hole for someone to just change the address to jump
to of "printf"... :)
--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
