mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #2176] sshd works within chroot, but not firejail chroot #1466
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#1466
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @publicsite on GitHub (Oct 13, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2176
Hello,
sshd within a firejail chroot doesn't work, whereas using sshd within a coreutils chroot does. Any help with this would be very much appreciated!
@reinerh commented on GitHub (Oct 13, 2018):
When you run:
you are starting a jail with the default profile, which will probably block access to some required files.
I don't know if it would solve your problem, but you can try starting with the ssh.profile (there is currently no profile for sshd, but maybe the ssh profile already helps). Otherwise you need to start sshd also in verbose mode and check what's going wrong.
@publicsite commented on GitHub (Oct 13, 2018):
Hi, I tried with the ssh.profile, I am using an older version of firejail so I did not have the ssh.profile, and had to remove some lines to get it to go at all, note that despite this no new lines were added to the ssh.profile to get the following output. I have also put the sshd -d verbose output for the command in my previous comment here for you.
@publicsite commented on GitHub (Oct 13, 2018):
I just tried to add
--seccomp.keep=lstat,lstat64,fstat,fstat64,open,openat,fstatat64,stat,stat64,brk,clock_gettime,close,exit,exit_group,futex,geteuid,geteuid32,getpgid,getpid,getrandom,gettimeofday,getuid,getuid32,madvise,mmap,mmap2,mremap,munmap,nanosleep,newselect,poll,pselect6,read,rt_sigprocmask,select,sigprocmask,time,write,socketcall,ioctlbut it produced the same result.
https://github.com/openssh/openssh-portable/blob/master/sandbox-seccomp-filter.c
@smitsohu commented on GitHub (Oct 13, 2018):
I think you'll also need to keep a bunch of capabilities. Fortunately someone else already did the work, just take a look at the apparmor profile:
https://gitlab.com/apparmor/apparmor/blob/master/profiles/apparmor/profiles/extras/usr.sbin.sshd
@publicsite commented on GitHub (Oct 13, 2018):
Running firejail with the following command didn't help.
sudo firejail --chroot="$PWD"/jails/rootfs --shell=/bin/sh /bin/sh --caps.keep=sys_chroot,sys_resource,sys_tty_config,net_bind_service,chown,fowner,kill,audit_control,audit_write,dac_override,dac_read_search,sys_ptrace,fsetid,setuid,setgid,ipc_lock --seccomp.keep=lstat,lstat64,fstat,fstat64,open,openat,fstatat64,stat,stat64,brk,clock_gettime,close,exit,exit_group,futex,geteuid,geteuid32,getpgid,getpid,getrandom,gettimeofday,getuid,getuid32,madvise,mmap,mmap2,mremap,munmap,nanosleep,newselect,poll,pselect6,read,rt_sigprocmask,select,sigprocmask,time,write,socketcall,ioctl
Also running:
sudo firejail --chroot="$PWD"/jails/rootfs --shell=/bin/sh --name="wibble" --noprofile /bin/sh
Did not work
@publicsite commented on GitHub (Oct 13, 2018):
Boom.
Have progress.
sudo firejail --noprofile chroot jails/rootfs /bin/sh
Works, so can now start adding profile. Unfortunate --chroot option doesn't fly though.
@smitsohu commented on GitHub (Oct 13, 2018):
Just an observation: The seccomp list from openssh-portable and the apparmor capability list don't match. This means that syscalls are missing or the list of capabilities is actually too long, or a combination of both.
I strongly recommend to upgrade to a more recent firejail version. 0.9.38 effectively has reached EOL.
@publicsite commented on GitHub (Oct 14, 2018):
That might be an issue, but the more troubling issue is that the --chroot option in firejail doesn't work with sshd.
The command I have at the moment is:
sudo firejail \ --ignore=noroot \ --noprofile \ --caps.keep=sys_chroot,sys_resource,sys_tty_config,net_bind_service,chown,fowner,kill,audit_control,audit_write,dac_override,dac_read_search,sys_ptrace,fsetid,setuid,setgid,ipc_lock \ chroot jails/rootfs /bin/sh \ --seccomp.keep=exit_group,chroot,mprotect,set_thread_area,access,lstat,lstat64,fstat,fstat64,open,openat,fstatat64,stat,stat64,brk,clock_gettime,close,exit,exit_group,futex,geteuid,geteuid32,getpgid,getpid,getrandom,gettimeofday,getuid,getuid32,madvise,mmap,mmap2,mremap,munmap,nanosleep,poll,pselect6,read,rt_sigprocmask,select,sigprocmask,time,write,socketcall,ioctlBut the following syscalls were added to the seccomp list purely because of the chroot hack, rather than bein able to use the firejail option:
exit_group,chroot,mprotect,set_thread_area,access`
Note that a way to escape a chroot is by using chroot, so it's not secure as it stands.
@publicsite commented on GitHub (Oct 14, 2018):
Ignore me, it's still an issue.
@publicsite commented on GitHub (Oct 14, 2018):
@crass commented on GitHub (Oct 14, 2018):
@publicsite try this branch and the
Error: failed to run /run/firejail/lib/fseccomp. I'm pretty sure this is because I didn't account for chroots in #2186. Hopefully everything else will work too.@publicsite commented on GitHub (Oct 14, 2018):
@crass
Hi, I checked out using
git clone https://github.com/crass/firejail -b fix-chroot-not-mount-firejail-libdirBut it still gave:
Error: failed to run /run/firejail/lib/fseccompAfter compilation and installation.
@crass commented on GitHub (Oct 15, 2018):
Hmm, actually, I'm not getting that error, with or without the changes in my branch. So I'm thinking that the chroot doesn't need the
/run/firejail/libdir. I guess to debug this further, we'll need to know exactly how you're setting up your chroot. If you runsudo chroot "$PWD/jails/rootfs", do you get a shell?@publicsite commented on GitHub (Oct 15, 2018):
That's weird.
All I did was clone the repo, run
./configuremakesudo make installthen
sudo /usr/local/bin/firejail --chroot="$PWD/jails/rootfs" --noprofile --shell=/bin/sh \ --caps.keep=sys_chroot,sys_resource,sys_tty_config,net_bind_service,chown,fowner,kill,audit_control,audit_write,dac_override,dac_read_search,sys_ptrace,fsetid,setuid,setgid,ipc_lock \ --seccomp.keep=setgroups,setgroups32,lstat,lstat64,fstat,fstat64,open,openat,fstatat64,stat,stat64,brk,clock_gettime,close,exit,exit_group,futex,geteuid,geteuid32,getpgid,getpid,getrandom,gettimeofday,getuid,getuid32,madvise,mmap,mmap2,mremap,munmap,nanosleep,poll,pselect6,read,rt_sigprocmask,select,sigprocmask,time,write,socketcall,ioctlexecvp: No such file or directory Error: failed to run /run/firejail/lib/fseccomp Error: proc 8481 cannot sync with peer: unexpected EOF Peer 8482 unexpectedly exited with status 1when I use coreutils chroot as you said, it works ok.
@smitsohu commented on GitHub (Oct 15, 2018):
It should work if you bind-mount /usr{,local/}lib/firejail on $PWD/jails/rootfs/run/firejail/lib
In the moment firejail doesn't take care of this itself. I think we need to change this.
Don't be surprised if /bin/sh still doesn't run with your command. The seccomp filter is too restrictive for /bin/sh and kills it immediately, as you can see in the syslog.
@smitsohu commented on GitHub (Oct 15, 2018):
I've pushed a fix, could you please build from latest git and let us know if this works?
Thanks!
@smitsohu commented on GitHub (Oct 15, 2018):
My impression is that the seccomp filter you found is indeed not suitable for the sshd parent process. If I understand it right, you can enable it with
UsePrivilegeSeparation sandboxin/etc/ssh/sshd_config, and it will then restrict an sshd child process.See here for an example configuration making use of this.
A seccomp filter for the sshd parent process probably has to be much more permissive. For building seccomp filters from scratch you may want to take a look at the seccomp guide and #404 .
@publicsite commented on GitHub (Oct 15, 2018):
@smitsohu
Hi, I git cloned again with your changes, but unfortunately I get the same
Error: failed to run /run/firejail/lib/fseccompJust like to add; when firejail is used like so:
sudo firejail --noprofile chroot jails/rootfs /bin/shOr like so:
sudo /usr/local/bin/firejail --noprofile --chroot=jails/rootfs /bin/shBoth sshd and /bin/sh work, it's just the capabilities whitelist (--seccomp.keep) that doesn't work with the chroot option, which is almost certainly due to the /run/firejail/lib/fseccomp error.
I'm not sure if this makes a difference, but when I
ls /run/firejail/lib/on the host, the directory is empty.@publicsite commented on GitHub (Oct 15, 2018):
Hi,
fseccomp has been placed in /usr/local/lib/firejail not /run/firejail/lib
Is there any way of changing where firejail looks for fseccomp?
@crass commented on GitHub (Oct 16, 2018):
@publicsite can you try this repo and see if you get the same issue? Also some changes around
/run/firejail/libhave happened recently, are you sure you've rungit pullin themasterbranch to get the latest commits?@publicsite commented on GitHub (Oct 16, 2018):
@crass
It's not finding fseccomp in /usr/local/lib/firejail
@crass commented on GitHub (Oct 16, 2018):
@publicsite I get this error when running that command:
I'm not understand how you're getting around the check that make sure you're not passing caps and seccomp args...
--chrootenforces default caps and seccomp. What are you doing that you're not telling us? 😉EDIT: Hmm, you're running as root that's why....
@publicsite commented on GitHub (Oct 16, 2018):
@crass
That's weird, and certainly not the error I get.
Either way, it's redonculous that I can't pass seccomp args with chroot.
Would be nice to tell firejail how to find fseccomp in /usr/local/lib/firejail
@crass commented on GitHub (Oct 16, 2018):
Yeah I realized you are by passing that check cause you're running as root. And yes I agree its ridiculous even for a regular user. I hope to change that. Try this branch with the command in the output below (changing paths as needed) and see if you get the same output. There are some added
seccomp.keepsyscalls from yours, and almost certainly there will need to be more to get it fully functioning. But the seccomp filter is working for me.Command:
Output:
@publicsite commented on GitHub (Oct 16, 2018):
@smitsohu
Hi,
I changed RUN_FIREJAIL_LIB_DIR before compiling, and got a different error.
I have left a comment at:
be1e3b02bf@publicsite commented on GitHub (Oct 16, 2018):
Hi,
/run/firejail/lib/firejail/fseccomp now exists, both in the chroot (as mount bind) and also on the host, but it's giving the same error:
I'm guessing it's not actually possible at this point in time to use a seccomp whitelist with the chroot option.
@crass commented on GitHub (Oct 16, 2018):
@publicsite I believe I've done so successfully. When you ran the command above, the strace should have written a file
/tmp/firejail.strace. Can you attach that file to a comment here? That should give me a better idea of what is actually happening. Using xz to compress it might be nice as well.@chiraag-nataraj commented on GitHub (May 21, 2019):
@publicsite Is this still an issue?
@publicsite commented on GitHub (May 21, 2019):
chiraag-nataraj
I'm not sure, ended up with different solution, and that's what I'm using at present ... though could try giving it another test to see if anything has differed since. Built myself a nice chroot when issue came up last October, so something might have changed 6 months on ...
@chiraag-nataraj commented on GitHub (May 21, 2019):
Okay! If that's the case, I guess I'll go ahead and close this issue for now. If you decide to revisit and run into this, please feel free to re-open!