[Dev] Tizen 3.0 proposal for applications launch

Carsten Haitzler c.haitzler at samsung.com
Wed Oct 16 11:48:37 GMT 2013

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.

More information about the Dev mailing list