shared libs

shared libs

[André Coelho]

Hello,


instead of getting shared libraries on HD, use a remote host, to get them

all we need is .text,.data, and .bss , and stack /heap preferred 
addresses (if we are talking about elf format)

the linkage, would be done on localhost


What do you think of this?

regard

Andre Coelho

-- 
André Albergaria Coelho
andrealbergaria@gmail.com

Re: shared libs

[Theodore Ts'o]

On Sat, Jan 04, 2025 at 09:59:06PM +0000, André Coelho wrote:
> 
> instead of getting shared libraries on HD, use a remote host, to get them
> 
> all we need is .text,.data, and .bss , and stack /heap preferred addresses
> (if we are talking about elf format)

This can be done today making the shared library available using NFS.
Of course, there are downsides about making shared libraries via a
remote host, regardless of the details of how this is done:

  * You have to trust the remote host to send you a legitimate shared
    library; if the instructions in the shared library are modified by
    a remote attacker, they can control what is run on the local host,
    resulting in a potential trojan horse attack.

  * There is a potential performance impact if it is slower to access
    the remote host as compared to a local storage device (whether it
    is a HDD or a SSD).

There are ways of mitigating some of these; for example, you could use
an integrity protected network connection (which is supported by NFS,
for example), or if you use a networked block device to mount a file
system, you could use fsverity to make sure that a man-in-the-middle
attacker can't modify the shared library blocks in transit.  If the
fsverity merkle tree is protected using public key signature (this is
done to protect ChromeOS's root file system, so support of this is
available today), this can also provide the necessary integrity
protection.

Cheers,

					- Ted