Firejail: Viber profile report error!

[nemanjaf]

I tested firejail 0.9.52-1 with Viber desktop application on three Linux distribution and I always get the same warnings and error.

Warning: skipping alternatives for private /etc
Warning: skipping proxychains.conf for private /etc
Warning: /sbin directory link was not blacklisted
Warning: /usr/sbin directory link was not blacklisted
Error: no suitable Viber executable found

Has anyone tested a Viber profile before make commit?

[SkewedZeppelin]

@chiraag-nataraj created the Viber profile long ago, I cleaned it up and added it. I did not not test it.

Can you edit /etc/firejail/Viber.profile, disable all the options, and re-enable them one by one until it crashes? I'd try commenting private-bin first. Thanks.

[nemanjaf]

I commented _Viber.local_ and _globals.local_ lines because the specified files do not exist. Also, I change path for _disable-common.inc_, _disable-devel.inc_, _disable-passwdmgr.inc_ and _disable-programs.inc_ files from _/etc/firejail/_ to _/usr/share/defaults/firejail/_.

/opt/viber/Viber: error while loading shared libraries: libqrencode.so: cannot open shared object file: No such file or directory

In the end, I had to comment these options also:

noroot
protocol unix,inet,inet6
seccomp

From my point of view, noroot and seccomp are very significant.

[netblue30]

Take a look at nonewprivs line in the profile. If it is working with it, probably one of the syscalls in default seccomp filter is killing it. I would say if nonewprivs is working, you should be fine.

Where is libqrencode.so installed?

[chiraag-nataraj]

I had to comment the following from my Viber profile:

whitelist ${HOME}/.ViberPC
whitelist ${DOWNLOADS}
noexec ${HOME}

I'm not really sure why, though.

[chiraag-nataraj]

Okay, I came up with a workaround for the issue with the home folder. Instead of using whitelist, I end up using private-home. I guess all this means is that I'll have to manually copy files from the Downloads directory if I want to store them using --get, but...oh well. Definitely more secure than what I had earlier. Also, apparently Viber is doing this super unsafe thing where it's making something executable in the home folder - I don't know what exactly and I don't know why, but it crashes/exits if I keep noexec ${HOME}. Also, apparently it needs root because of the permissions on the libraries, but that doesn't really make sense given that they have o+rx permissions.

[chiraag-nataraj]

@nemanjaf, see if the attached profile works for you :slightly_smiling_face:
Viber.txt

[smitsohu]

@chiraag-nataraj It is a bit speculative, but do you wanna give it a try with env QML_DISABLE_DISK_CACHE=1? In order to safe the noexec and maybe the whitelisting....

[chiraag-nataraj]

WHAT IS THIS MAGIC :open_mouth::open_mouth::open_mouth:
Yes, it worked!!!
[Edit] Still need to disable noroot, but given that we're restricting it from having access to any actual files _and_ heavily limiting the binaries it has access to...seems like it's suboptimal but tolerable.

[smitsohu]

@chiraag-nataraj The magic is taken care of by a bug in Qt ;)

[chiraag-nataraj]

Ugh. Why is this even a thing? :stuck_out_tongue_winking_eye: Anyway, at least we have a workaround :joy:

[smitsohu]

I googled a bit for Viber error messages, the app seems to use Qt webengine.

This means there might be a Chromium sandbox somewhere in the app, and this in turn could explain why the seccomp option works fine for @chiraag-nataraj (with Debian), but breaks on distros with unprivileged user namespaces enabled (@nemanjaf what distro do you use?).

If that's the problem, we would need to allow chroot syscalls and in the profile replace seccomp with the following long line:
seccomp.drop @clock,@cpu-emulation,@debug,@module,@obsolete,@raw-io,@reboot,@resources,@swap,acct,add_key,bpf,fanotify_init,io_cancel,io_destroy,io_getevents,io_setup,io_submit,ioprio_set,kcmp,keyctl,mount,name_to_handle_at,nfsservctl,ni_syscall,open_by_handle_at,personality,pivot_root,process_vm_readv,ptrace,remap_file_pages,request_key,setdomainname,sethostname,syslog,umount,umount2,userfaultfd,vhangup,vmsplice.

For protocol, I think it would be interesting to see if protocol unix,inet,inet6,netlink solves the issue. Some messenger apps seem to need netlink for part of their functionality.

To cut a long story short: @nemanjaf could you please try out if the following profile works for you? It is build on improvements suggested by @chiraag-nataraj :+1: and tries to take account of the various Qt peculiarities

noblacklist ${HOME}/.ViberPC

include /etc/firejail/disable-common.inc
include /etc/firejail/disable-devel.inc
include /etc/firejail/disable-passwdmgr.inc
include /etc/firejail/disable-programs.inc

whitelist ${DOWNLOADS}
whitelist ${HOME}/.ViberPC
include /etc/firejail/whitelist-common.inc

caps.drop all
ipc-namespace
netfilter
nodvd
nogroups
nonewprivs
# noroot
notv
protocol unix,inet,inet6,netlink
seccomp.drop @clock,@cpu-emulation,@debug,@module,@obsolete,@raw-io,@reboot,@resources,@swap,acct,add_key,bpf,fanotify_init,io_cancel,io_destroy,io_getevents,io_setup,io_submit,ioprio_set,kcmp,keyctl,mount,name_to_handle_at,nfsservctl,ni_syscall,open_by_handle_at,personality,pivot_root,process_vm_readv,ptrace,remap_file_pages,request_key,setdomainname,sethostname,syslog,umount,umount2,userfaultfd,vhangup,vmsplice
shell none

disable-mnt
private-bin sh,dig,awk,xdg-mime,cut,touch,mv
private-etc hosts,fonts,mailcap,resolv.conf,X11,pulse,alternatives,localtime,nsswitch.conf,ssl,proxychains.conf
private-tmp

env QML_DISABLE_DISK_CACHE=1
noexec ${HOME}
noexec /tmp

[chiraag-nataraj]

You could also try env QTWEBENGINE_DISABLE_SANDBOX=1 to disable the Qt sandbox.

[netblue30]

Doing QML_DISABLE_DISK_CACHE=1 and QTWEBENGINE_DISABLE_SANDBOX=1 by default (hardcoded).

commit: https://github.com/netblue30/firejail/commit/1e7045b55cc1e189dba6d9ed21c05c90663f3736

Grab the latest from git and give it a try. Thanks.

[netblue30]

Moving the discussion to #1736, thanks for the bug.