All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: "André Coelho" <andrealbergaria@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: shared libs
Date: Mon, 6 Jan 2025 09:38:30 -0500	[thread overview]
Message-ID: <20250106143830.GD1284777@mit.edu> (raw)
In-Reply-To: <9c6593e7-4527-463b-8a9a-96f5523060b6@gmail.com>

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

      reply	other threads:[~2025-01-06 14:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-04 21:59 shared libs André Coelho
2025-01-06 14:38 ` Theodore Ts'o [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250106143830.GD1284777@mit.edu \
    --to=tytso@mit.edu \
    --cc=andrealbergaria@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.