Page MenuHomeFreeBSD

rtld: allow attaching to JID after loading
AbandonedPublic

Authored by fabian.freyer_physik.tu-berlin.de on Feb 20 2019, 10:58 PM.
Tags
None
Referenced Files
F99275599: D19277.diff
Mon, Oct 7, 10:47 PM
Unknown Object (File)
Mon, Sep 16, 11:06 PM
Unknown Object (File)
Sun, Sep 8, 5:53 AM
Unknown Object (File)
Sep 7 2024, 6:37 PM
Unknown Object (File)
Aug 26 2024, 11:56 PM
Unknown Object (File)
Aug 23 2024, 7:36 PM
Unknown Object (File)
Aug 17 2024, 11:32 AM
Unknown Object (File)
Aug 15 2024, 10:19 AM

Details

Reviewers
kib
jamie
Summary

Allow executing dynamic executables within a jail without them or their libraries being present within the filesystem root of the jail.

Test Plan
jail -c path=/ jid=1234 persist
/libexec/ld-elf.so.1 -j 1234 /bin/ls

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

fabian.freyer_physik.tu-berlin.de retitled this revision from [WIP] rtld: allow attaching to JID after loading to rtld: allow attaching to JID after loading.
fabian.freyer_physik.tu-berlin.de edited the test plan for this revision. (Show Details)
  • finalized patch
kevans added a subscriber: kevans.

Tagging kib and jamie to start with, perhaps.

kib requested changes to this revision.Feb 22 2019, 4:58 PM

You do understand that with your patch, parts of the image code is executed un-jailed, and part of it is executed jailed, all sudden for it.

I do not see why cannot you do something similar (or perhaps better) with LD_PRELOAD. ld-elf.so.1 duty is to link the application, not to provide random OS-level services.

This revision now requires changes to proceed.Feb 22 2019, 4:58 PM
In D19277#412997, @kib wrote:

You do understand that with your patch, parts of the image code is executed un-jailed, and part of it is executed jailed, all sudden for it.

Yes. The point is that linking happens outside the jail, so that the executable and libraries do not have to reside within the jail filesystem.
This allows for e.g. jails with path=/var/empty or read-only filesystems.

I do not see why cannot you do something similar (or perhaps better) with LD_PRELOAD.

How?

ld-elf.so.1 duty is to link the application, not to provide random OS-level services.

For static binaries, this is possible using an open, jail_attach, fexecve wrapper (see e.g. https://gitlab.com/jetpack-containers/jexec-static), however, it's not possible to perform any OS-level setup between link time and execution time.

An alternative approach might be to publish the _rtld symbol and allow passing in the auxiliary vector, env and argv - and then write a wrapper that calls _rtld, then jail_attach, then jump into the entry point of the executable. Would this approach be better?

In D19277#412997, @kib wrote:

You do understand that with your patch, parts of the image code is executed un-jailed, and part of it is executed jailed, all sudden for it.

Yes.

No.

The point is that linking happens outside the jail, so that the executable and libraries do not have to reside within the jail filesystem.

Not linking, but some code execution of the application happens outside the jail.
At very least, all constructors are executed there.

This allows for e.g. jails with path=/var/empty or read-only filesystems.

I do not see why cannot you do something similar (or perhaps better) with LD_PRELOAD.

How?

Write dso which calls jail_attach() in its constructor.

ld-elf.so.1 duty is to link the application, not to provide random OS-level services.

In D19277#413005, @kib wrote:

At very least, all constructors are executed there.

You're right, I'll abandon this revision and try to look at the other approach.

I do not see why cannot you do something similar (or perhaps better) with LD_PRELOAD.

How?

Write dso which calls jail_attach() in its constructor.

Is there a way I can guarantee this gets called as the first constructor?

@kib, could RTLD_LO_EARLY help here?

I do not see how the internal rtld flag can be useful for you.

LD_PRELOAD libraries' constructors are called as soon as possible in the global dependency order. Simply, this means that they are called right after all needed libraries are initialized. So I suspect that you do not need to arrange anything special for LD_PRELOAD to give you the required functionality.