Kernel+Userland: Add auto-jailing symlink of dynamic loader, introduce the new set-elf-jailed utility

[supercomputer7]

Relies on #22968. So this is a draft for now. The idea is to enable auto-jailing on programs by changing their dynamic loader to another which is almost identical, but enters jail-mode just before jumping to the program main function.

[DanShaders]

LGTM otherwise

[timschumi]

I see the idea, but I can't help the feeling that there are better ways to signal this to the kernel (either temporarily or permanently) than building an entirely different DynamicLoader and patchelfing the files. Things like xattrs and environment variables come to mind.

[supercomputer7]

I see the idea, but I can't help the feeling that there are better ways to signal this to the kernel (either temporarily or permanently) than building an entirely different DynamicLoader and patchelfing the files. Things like xattrs and environment variables come to mind.

What about filesystems that don't support xattrs? Patching ELFs is a permanent solution and will work across all shells, filesystems, etc. Environment variables are also useful, but frankly it's more a temporary solution than a permanent one.

I don't mind having multiple ways to set a program into jail mode, and I think this is a completely valid way as well.

[supercomputer7]

If adding a second dynamic loader is considered a bad idea (which I don't really think it is, because it's simple and makes it easy to check if an ELF file is auto-jailed by just running file), we could add an option to do this in the regular dynamic loader - we will add an option in the args parsing, and an environment variable as well. We could then add a special argument in the aux vector that will signal this (secure mode come to mind) or using a special section in an ELF file for this (so patchelf is still needed, or some replacement of our own).

Adding support for xattrs is also not-a-bad idea, just not something I'd want to mess around with for now (surely not for this).

[supercomputer7]

Another good idea - make /usr/lib/ldjail.so a symlink to the original loader, so we don’t have 2 almost identical loaders on disk. If you run a program through the symlink, the loader can detect this (we could add a passing of the basename of the loader in the aux vector, I think this should work fine) and then set the program into jail mode accordingly.

[supercomputer7]

Another good idea - make /usr/lib/ldjail.so a symlink to the original loader, so we don’t have 2 almost identical loaders on disk. If you run a program through the symlink, the loader can detect this (we could add a passing of the basename of the loader in the aux vector, I think this should work fine) and then set the program into jail mode accordingly.

I implemented this idea and it looks really OK now.
This PR now relies on #24791 to be merged first.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions!

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions!

[supercomputer7]

This is stale and sadly I don't have the time right now to keep it open. I might re-open it sometime in the future, if it seems like an interesting feature to someone in the project :)

[DanShaders]

Off: clearly, you haven't mastered art of removing "stale" label without making any changes for months (ref 24567) :^)

[timschumi]

Off: clearly, you haven't mastered art of removing "stale" label without making any changes for months (ref 24567) :^)

Just saying, but that is the textbook definition of stale. Maybe not necessarily 100% for the Coroutine PR, since we also had off-GitHub discussions with a somewhat unclear outcome, but it definitely would be when applied to certain PRs that have been subject to repeated bumps (e.g. 24774).

Removing/invalidating stale labels should be reserved for cases where the PR isn't blocking on anything else but maintainer/reviewer attention. The permission to label issues and PRs isn't a free pass for keeping PRs in the queue when they shouldn't be.