Skip to content
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

Should we disallow calling execute_command_line? #47

Open
milancurcic opened this issue Sep 13, 2022 · 4 comments
Open

Should we disallow calling execute_command_line? #47

milancurcic opened this issue Sep 13, 2022 · 4 comments
Labels
question Further information is requested security Security-related issues

Comments

@milancurcic
Copy link
Member

It's currently allowed and users can run shell commands in the container. Should we disallow calling execute_command_line, even considering #46?

@milancurcic milancurcic added question Further information is requested security Security-related issues labels Sep 13, 2022
@awvwgk
Copy link
Member

awvwgk commented Sep 13, 2022

There is also the extension system which can run shell commands and we can still popen a process via bind(c). Best would be to strip down our docker image to only include the necessary libraries. Not having wget and curl might already help, don't know whether we can delete the shell and have fpm still work. Maybe a distroless container might be useful.

@ivan-pi
Copy link
Member

ivan-pi commented Sep 13, 2022

Would it be possible to inject code (or maybe a preprocessor define) that overwrites these functions and force them to generate a compile-time error? But I guess even this can be overridden with a declaration such as?

intrinsic :: execute_command_line

Perhaps it's possible to remove the symbol from libgfortran.a (or the shared library)?

@arjenmarkus
Copy link
Member

arjenmarkus commented Oct 11, 2022 via email

@milancurcic
Copy link
Member Author

Thank you @ivan-pi and @arjenmarkus. Both are viable, but rather than injecting code we can detect the offending code in the function that processes the request, and return a helpful error message to the frontend.

Alternatively, we could disallow it on the frontend. The user would still be able to submit such code directly to the API until #34 is resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested security Security-related issues
Projects
None yet
Development

No branches or pull requests

4 participants