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

Extra security features for terminal-enabled containers #23

Open
1 of 2 tasks
achimnol opened this issue Nov 1, 2016 · 0 comments
Open
1 of 2 tasks

Extra security features for terminal-enabled containers #23

achimnol opened this issue Nov 1, 2016 · 0 comments
Assignees
Milestone

Comments

@achimnol
Copy link
Member

achimnol commented Nov 1, 2016

  • Prevent killing the REPL daemon by intercepting kill() system call to a specific pid.
  • Prevent access to the REPL code (/home/sorna)
@achimnol achimnol self-assigned this Nov 1, 2016
achimnol added a commit that referenced this issue Nov 1, 2016
 * Now it correctly prevents killing the REPL daemon itself,
   while allowing other signals transparently.
   (e.g., now "Ctrl+Z on vim" to set it background works.)
achimnol added a commit that referenced this issue Feb 14, 2017
 * Now shell's job control (e.g., Ctrl+Z) works correctly.

   - It uses PTRACE_SEIZE instead of PTRACE_ATTACH/PTRACE_TRACEME
     to handle group-stop scenarios properly.
     (introduce Linux kernel 3.4 or later)

   - Improved jail and intra-jail synchronization on startup.

 * Optimized the tracer loop of jail so that it uses only one
   goroutine to monitor child signals.
   (No more recreation for every signal!)

 * Set TERM environment variable and let jail keep it.

 * Know problem:

   - To allow self-stopping in intra-jail, I had to allow "kill"
     syscall blindly.  Killing pid 1 is prevented by Docker but
     killing the jail is allowed.  Fortunately, the other parts of
     Sorna API service handles this situation well, notifying server
     termination to the user without leaking coroutines.

   - If we could remove already-installed seccomp filters in runtime
     then we can solve the above problem.
achimnol added a commit that referenced this issue Feb 14, 2017
 * Making two sets of seccomp filters because installing a new one
   replaces the previous one.
@inureyes inureyes added this to the 19.06 milestone Jun 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants