Firejail with grsecurity

[netblue30]

Moved from the blog:

Got a question regarding the “an existing sandbox was detected…” error. I’m running a grsec kernel, and I’ve got two users. User A has /usr/bin/firejail as the shell while user B has /bin/bash. When I bring up a terminal emulator (xterm, uxterm, or xfce terminal) in either of the users, I see this error. When I run firejail –tree, the processes shows up. Even when I log into something like TTY2 without a GUI, I get the same error when attempting to go into firejail or run something with firejail. Should I disable grsec’s chroot restrictions? I’ve tried disabling several (caps, fchdir, shmat, unix, ect) with out any success. When I run firejail without a grsec kernel, firejail works flawlessly. What do?

[password12345678]

Hi, thanks for responding to my inquiry so quickly!
Here's what I have in my config file http://pastebin.com/qk7zGHuj. The only exception is that I have TPE_RESTRICT_ALL and CHROOT_DENY_UNIX turned off in my sys turnable. I'm using the 4.2.6 kernel with grsecurity-3.1-4.2.6-201511141543.patch.

On a side note, I was messing around with my fstab, and found out that firejail can't have /usr/bin mounted in read-only. Here's what my fstab looks like now:
/dev/mapper/asdf-home /home ext4 nosuid,noatime,nodev 0 2
/dev/mapper/asdf-opt /opt ext4 discard,noatime,nosuid 0 2
/dev/mapper/asdf-usr--bin /usr/bin ext4 defaults,nosuid,noatime,rw 0 2
/dev/mapper/asdf-usr--local /usr/local ext4 defaults,nosuid,noatime,ro 0 2
/dev/mapper/asdf-usr--sbin /usr/sbin ext4 defaults,nosuid,,noatime,ro 0 2
/dev/mapper/asdf-var /var ext4 discard,noatime,nodev,nosuid 0 2
tmpfs /tmp tmpfs noatime,nosuid,nodev,size=2G 0 1

[netblue30]

I put a copy of your config here, in case it expires on pastebin:

CONFIG_GRKERNSEC=y
# CONFIG_GRKERNSEC_CONFIG_AUTO is not set
CONFIG_GRKERNSEC_CONFIG_CUSTOM=y
CONFIG_GRKERNSEC_PROC_GID=999
CONFIG_GRKERNSEC_TPE_UNTRUSTED_GID=996
CONFIG_GRKERNSEC_SYMLINKOWN_GID=998
CONFIG_GRKERNSEC_KMEM=y
CONFIG_GRKERNSEC_IO=y
CONFIG_GRKERNSEC_BPF_HARDEN=y
CONFIG_GRKERNSEC_PERF_HARDEN=y
CONFIG_GRKERNSEC_RAND_THREADSTACK=y
CONFIG_GRKERNSEC_PROC_MEMMAP=y
CONFIG_GRKERNSEC_KSTACKOVERFLOW=y
CONFIG_GRKERNSEC_BRUTE=y
# CONFIG_GRKERNSEC_MODHARDEN is not set
CONFIG_GRKERNSEC_HIDESYM=y
CONFIG_GRKERNSEC_RANDSTRUCT=y
CONFIG_GRKERNSEC_RANDSTRUCT_PERFORMANCE=y
CONFIG_GRKERNSEC_KERN_LOCKOUT=y
# CONFIG_GRKERNSEC_NO_RBAC is not set
CONFIG_GRKERNSEC_ACL_HIDEKERN=y
CONFIG_GRKERNSEC_ACL_MAXTRIES=3
CONFIG_GRKERNSEC_ACL_TIMEOUT=30
CONFIG_GRKERNSEC_PROC=y
# CONFIG_GRKERNSEC_PROC_USER is not set
CONFIG_GRKERNSEC_PROC_USERGROUP=y
CONFIG_GRKERNSEC_PROC_ADD=y
CONFIG_GRKERNSEC_LINK=y
CONFIG_GRKERNSEC_SYMLINKOWN=y
CONFIG_GRKERNSEC_FIFO=y
CONFIG_GRKERNSEC_SYSFS_RESTRICT=y
# CONFIG_GRKERNSEC_ROFS is not set
CONFIG_GRKERNSEC_DEVICE_SIDECHANNEL=y
CONFIG_GRKERNSEC_CHROOT=y
CONFIG_GRKERNSEC_CHROOT_MOUNT=y
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
CONFIG_GRKERNSEC_CHROOT_PIVOT=y
CONFIG_GRKERNSEC_CHROOT_CHDIR=y
CONFIG_GRKERNSEC_CHROOT_CHMOD=y
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
CONFIG_GRKERNSEC_CHROOT_MKNOD=y
CONFIG_GRKERNSEC_CHROOT_SHMAT=y
CONFIG_GRKERNSEC_CHROOT_UNIX=y
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
CONFIG_GRKERNSEC_CHROOT_NICE=y
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
CONFIG_GRKERNSEC_CHROOT_RENAME=y
CONFIG_GRKERNSEC_CHROOT_CAPS=y
CONFIG_GRKERNSEC_CHROOT_INITRD=y
CONFIG_GRKERNSEC_AUDIT_GROUP=y
CONFIG_GRKERNSEC_AUDIT_GID=997
CONFIG_GRKERNSEC_EXECLOG=y
CONFIG_GRKERNSEC_RESLOG=y
# CONFIG_GRKERNSEC_CHROOT_EXECLOG is not set
# CONFIG_GRKERNSEC_AUDIT_PTRACE is not set
CONFIG_GRKERNSEC_AUDIT_CHDIR=y
# CONFIG_GRKERNSEC_AUDIT_MOUNT is not set
CONFIG_GRKERNSEC_SIGNAL=y
CONFIG_GRKERNSEC_FORKFAIL=y
# CONFIG_GRKERNSEC_TIME is not set
# CONFIG_GRKERNSEC_PROC_IPADDR is not set
CONFIG_GRKERNSEC_RWXMAP_LOG=y
CONFIG_GRKERNSEC_DMESG=y
CONFIG_GRKERNSEC_HARDEN_PTRACE=y
CONFIG_GRKERNSEC_PTRACE_READEXEC=y
CONFIG_GRKERNSEC_SETXID=y
CONFIG_GRKERNSEC_HARDEN_IPC=y
CONFIG_GRKERNSEC_TPE=y
CONFIG_GRKERNSEC_TPE_ALL=y
# CONFIG_GRKERNSEC_TPE_INVERT is not set
CONFIG_GRKERNSEC_TPE_GID=996
CONFIG_GRKERNSEC_BLACKHOLE=y
CONFIG_GRKERNSEC_NO_SIMULT_CONNECT=y
CONFIG_GRKERNSEC_SOCKET=y
CONFIG_GRKERNSEC_SOCKET_ALL=y
CONFIG_GRKERNSEC_SOCKET_ALL_GID=995
CONFIG_GRKERNSEC_SOCKET_CLIENT=y
CONFIG_GRKERNSEC_SOCKET_CLIENT_GID=994
CONFIG_GRKERNSEC_SOCKET_SERVER=y
CONFIG_GRKERNSEC_SOCKET_SERVER_GID=993
CONFIG_GRKERNSEC_DENYUSB=y
# CONFIG_GRKERNSEC_DENYUSB_FORCE is not set
CONFIG_GRKERNSEC_SYSCTL=y
# CONFIG_GRKERNSEC_SYSCTL_DISTRO is not set
CONFIG_GRKERNSEC_SYSCTL_ON=y
CONFIG_GRKERNSEC_FLOODTIME=10
CONFIG_GRKERNSEC_FLOODBURST=6


CONFIG_PAX_KERNEXEC_PLUGIN=y
CONFIG_PAX_PER_CPU_PGD=y
CONFIG_PAX_USERCOPY_SLABS=y
# PaX
CONFIG_PAX=y
# PaX Control
# CONFIG_PAX_SOFTMODE is not set
CONFIG_PAX_EI_PAX=y
CONFIG_PAX_PT_PAX_FLAGS=y
CONFIG_PAX_XATTR_PAX_FLAGS=y
# CONFIG_PAX_NO_ACL_FLAGS is not set
CONFIG_PAX_HAVE_ACL_FLAGS=y
# CONFIG_PAX_HOOK_ACL_FLAGS is not set
CONFIG_PAX_NOEXEC=y
CONFIG_PAX_PAGEEXEC=y
CONFIG_PAX_EMUTRAMP=y
CONFIG_PAX_MPROTECT=y
CONFIG_PAX_MPROTECT_COMPAT=y
CONFIG_PAX_ELFRELOCS=y
CONFIG_PAX_KERNEXEC=y
CONFIG_PAX_KERNEXEC_PLUGIN_METHOD_BTS=y
# CONFIG_PAX_KERNEXEC_PLUGIN_METHOD_OR is not set
CONFIG_PAX_KERNEXEC_PLUGIN_METHOD="bts"
CONFIG_PAX_ASLR=y
CONFIG_PAX_RANDKSTACK=y
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y
CONFIG_PAX_MEMORY_SANITIZE=y
CONFIG_PAX_MEMORY_STACKLEAK=y
CONFIG_PAX_MEMORY_STRUCTLEAK=y
CONFIG_PAX_MEMORY_UDEREF=y
CONFIG_PAX_REFCOUNT=y
CONFIG_PAX_CONSTIFY_PLUGIN=y
CONFIG_PAX_USERCOPY=y
# CONFIG_PAX_USERCOPY_DEBUG is not set
CONFIG_PAX_SIZE_OVERFLOW=y
# CONFIG_PAX_SIZE_OVERFLOW_DISABLE_KILL is not set
CONFIG_PAX_LATENT_ENTROPY=y

[Kalle72]

The problem is related to the proc-restrictions of GrSec (CONFIG_GRKERNSEC_PROC=y, CONFIG_GRKERNSEC_PROC_USERGROUP=y or CONFIG_GRKERNSEC_PROC_USER=y). Assuming you have chosen "CONFIG_GRKERNSEC_PROC_USERGROUP=y" with the trusted group 123 then the user opening a firejail-instance must be member of group 123. Otherwise firejail cannot look onto /proc and fails with the "existing sandbox error" (I am on gentoo and tested it with my self-compiled hardened-kernel)

However, inserting the user into the trusted group 123 is more a workaround then a fix, because the user get rights he should not get.

One could overcome this problem if firejail would execute its instances as a special "user" (for example this user could be called firejail). (Polkit for example acts like that and uses the user polkitd for its actions. Therefore inserting polkitd into 123 solves all polkit related problems!)

Then one could put this special user (firejail) into the trusted group 123 without putting the regular user into the trusted group.

Additionally this would have one further advantage: With grsec one can forbid any network access to some user/group. Assuming that firejail opens a sandbox with the rights of the special user "firejail" one could forbid network access to the regular user but the regular user could open a program with network access via firejail. This leads to a regular user which can only access internet through firejail.

I hope this was understandable and not to chaotic ;-)

PS: If my suggestion is problematic, because one user is not sufficient if a bunch of regular users would use firejail at the same time on the same machine, one could introduce a firejail user named "user_firejail" for every regular user.

PPS: The "reply"-field on https://l3net.wordpress.com/projects/firejail/ does not work for me?!?

[netblue30]

Thanks for the write-up. I'll have to give it a try and see what is going on. What do you mean by "replay" field?

[Kalle72]

With reply-field I meant the field where one can write an answer.