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

firejail hanging when using strace, but ptrace is not allowed #2809

Open
reinerh opened this issue Jun 29, 2019 · 2 comments
Open

firejail hanging when using strace, but ptrace is not allowed #2809

reinerh opened this issue Jun 29, 2019 · 2 comments
Labels
bug Something isn't working

Comments

@reinerh
Copy link
Collaborator

reinerh commented Jun 29, 2019

A Debian user reported the issue, that firejail is just hanging, when he was using strace ls with a profile that had the ptrace syscall dropped, even though --allow-debuggers has been specified.

/usr/bin/firejail --allow-debuggers --profile=firefox strace /bin/ls

So there seem to be two issues:

  • why does firejail just hang, instead of terminating when the program tries to ptrace something
  • should --allow-debuggers specified on the command line not override the dropped syscalls from the profile? According to the manpage this should be the case.
@reinerh reinerh added the bug Something isn't working label Jun 29, 2019
@smitsohu
Copy link
Collaborator

smitsohu commented Jul 2, 2019

firejail --allow-debuggers --seccomp -> works
firejail --allow-debuggers --seccomp.drop=ptrace -> is broken

It seems that strace pauses soon after starting up, before any ptrace syscalls are issued:

set_robust_list(0x762e4e55aa20, 24) = 0
pause(

(obtained with something like sudo strace -ff -o trace firejail --noprofile --allow-debuggers --seccomp.drop=ptrace strace ls)

@rusty-snake
Copy link
Collaborator

rusty-snake commented Aug 22, 2019

allow-debuggers: Allow tools such as strace and gdb inside the sandbox by whitelisting system calls ptrace and process_vm_readv.

seccomp: Enable seccomp filter and blacklist the syscalls in the default list (@default).

whats wrong?

  • seccomp doesn't use thes default list
  • allow-debuggers doesn't whitelist syscalls

whats realy happening?

seccomp blacklist the syscalls in @default-nodebuggers unless allow-debuggers is given, the it use @default

=> allow-debuggers switch the list used by seccomp

if (!allow_debuggers)
r = syscall_check_list("@default-nodebuggers", filter_add_blacklist, fd, 0, NULL);
else
r = syscall_check_list("@default", filter_add_blacklist, fd, 0, NULL);

(TODO: update manpage) [EDIT] #2940 [/EDIT]

whats the issue with seccomp.drop?

seccomp.drop: Enable seccomp filter, and blacklist the syscalls or the syscall groups specified by the command.

seccomp.drop use always the given list of syscalls/groups and no group by default, so allow-debuggers can't swtich this. Here allow-debuggers would have to work like noblacklist in profiles, but this is not implemented.

(void) allow_debuggers; // todo: to implemnet it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants