-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kernel+Userland: Add auto-jailing symlink of dynamic loader, introduce the new set-elf-jailed
utility
#24764
Conversation
22b6e04
to
900598d
Compare
set-elf-jailed
utilityset-elf-jailed
utility
900598d
to
b869faf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM otherwise
b869faf
to
0880707
Compare
0880707
to
b37060c
Compare
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 |
What about filesystems that don't support 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. |
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 Adding support for |
Another good idea - make |
b37060c
to
457fdab
Compare
set-elf-jailed
utilityset-elf-jailed
utility
I implemented this idea and it looks really OK now. |
457fdab
to
9f78bf4
Compare
9167430
to
7d2fb8d
Compare
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! |
In particular, try to make it obvious as possible that we don't want to fail after a certain point (when committing to the new ELF image). To implement this, there's a new method called commit_exec that can't fail, which is called after we disable the scope guard of reverting back to the old memory space. All allocations are done beforehand, on the do_exec method, so in case of failure reverting back is easier.
This will be useful later on when we add a symlink to the ELF program interpreter, thus enabling it to auto-jail the actual program.
Instead of manually running `runc` to set jail-mode on running programs, we could just create another version of the DynamicLoader which enters jail-mode just before running the loaded program.
In the previous commit, we added a another version of the DynamicLoader which enters jail-mode just before running the loaded program. Then, using a special utility, we can enforce using this dynamic loader on specific programs on which we desire to run in jail-mode.
7d2fb8d
to
6973406
Compare
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! |
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 :) |
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. |
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.