Integrate Capabilities in Open-Lambda #301
Conversation
|
Great progress! Let's do one case at a time, each in different PRs: How about this first? "right before forking a Leaf to run the user code". But is it before, or after forking? For you four questions:
|
|
|
||
| capList[0] = cap; | ||
| if (cap_set_flag(caps, CAP_EFFECTIVE, 1, capList, setting) == -1) { | ||
| cap_free(caps); |
There was a problem hiding this comment.
One of the nice things about a goto is it gives you a single place to clean things up, like this:
if (caps != NULL)
cap_free(caps);
There was a problem hiding this comment.
@tylerharter I actually didn't get what you mean here. I tried to use the goto statement already. Is there an even better way to do it?
| @@ -8,6 +9,71 @@ | |||
| #include <sys/types.h> | |||
| #include <sys/wait.h> | |||
| #include <seccomp.h> | |||
| #include <sys/capability.h> | |||
|
|
|||
| static int modify_cap_impl(int cap, int setting) { | |||
There was a problem hiding this comment.
To what extent can we just create Python wrappers around the cap API (can_get_proc, cap_set_flag, etc), and then have the logic using it in Python code only?
There was a problem hiding this comment.
@tylerharter I couldn't actually find a native way to do this in Python (atleast at a granular level) and then came across the seccomp code in this file. It feels like we should be able to do a lot with the wrappers - like we have good amount of control over how we want to expose these functions to Python. Is there a concern around doing it in this way?
We may have to do it in a different way (or use an external module?) for dropping privileges in sock.go since these would only work in Python.
min-image/runtimes/python/server.py
Outdated
| @@ -208,6 +208,7 @@ def main(): | |||
| file.write(pid) | |||
| print(f'server.py: joined cgroup, close FD {fd_id}') | |||
|
|
|||
| # drop privileges here | |||
There was a problem hiding this comment.
Can we make capability dropping optional, via config, like it is for seccomp? https://github.com/open-lambda/open-lambda/blob/main/min-image/runtimes/python/server.py#L189
There was a problem hiding this comment.
@tylerharter I added the command line argument for enabling capabilities as well. However, we'll need to pass the flag on to everywhere we drop capabilities - to check it and drop only if it's true. Wondering what would be the best way to do that.
|
@tylerharter My bad, I meant to say Okay sure, that makes sense. I'll start with |
|
@tylerharter "How about this first? "right before forking a Leaf to run the user code". But is it before, or after forking?" Taking this scenario first, I'm not sure exactly which one would be better or what the difference in the impact would be - dropping capabilities before vs after? |
Upon looking at the code (and the workshop slides), I found 3 possible places where we might drop privileges:
freshProc()[src/worker/sandbox/sock.go] right before exec-ing theserver.py.fork_server()[min-image/runtimes/server.py] right before the while loop that forks a new Zygotestart_container()[min-image/runtimes/server.py] right before forking a Leaf to run the user code.Some general questions I have:
web_server.pyorfork_server.pyinvoked? (EDIT: I meantweb_server()andfork_server()functions inserver.pymy bad)subefore I can navigate to the directory and create a lambda function with my code. Is it possible that none of this is run as root right from the beginning itself so this issue doesn't occur either? Or maybe the base directory can be initialized with more relaxed permissions?stracethe system calls (or if we know ones that are needed already) to see which capabilities they need and then iteratively add and test them to see if all things work as expected. Which also brings me to another question