Description of problem: SELinux won't allow openfortivpn to run resolvconf. Version-Release number of selected component (if applicable): openfortivpn-1.12.0-1.fc30 How reproducible: When SELinux is on (Fedora 30 and 31, EPEL 7 and 8). Steps to Reproduce: 1. Attempt to connect to a FortiGate appliance with openfortivpn, make sure /usr/sbin/resolvconf is available. 2. See SELinux message. Actual results: SELinux is preventing openfortivpn from execute access on the file /usr/bin/bash. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that openfortivpn should be allowed execute access on the bash file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'openfortivpn' --raw | audit2allow -M my-openfortivpn # semodule -X 300 -i my-openfortivpn.pp Additional Information: Source Context system_u:system_r:openfortivpn_t:s0 Target Context system_u:object_r:shell_exec_t:s0 Target Objects /usr/bin/bash [ file ] Source openfortivpn Source Path openfortivpn Port Host sag-00828 Source RPM Packages Target RPM Packages bash-5.0.11-1.fc31.x86_64 Policy RPM selinux-policy-3.14.4-49.fc31.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name sag-00828 Platform Linux sag-00828 5.5.8-200.fc31.x86_64 #1 SMP Thu Mar 5 21:28:03 UTC 2020 x86_64 x86_64 Alert Count 1 First Seen 2020-03-12 08:34:04 CET Last Seen 2020-03-12 08:34:04 CET Local ID a1a85afc-a1f0-4a66-89f5-046af86de2da Raw Audit Messages type=AVC msg=audit(1583998444.342:331): avc: denied { execute } for pid=5566 comm="openfortivpn" name="bash" dev="dm-0" ino=917654 scontext=system_u:system_r:openfortivpn_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0 Hash: openfortivpn,openfortivpn_t,shell_exec_t,file,execute Additional info: See https://github.com/adrienverge/openfortivpn/issues/563.
Hi, It is interesting that on my systems /usr/sbin/resolvconf is a symlink to /bin/resolvectl which is an elf binary. Were there any changes made on your system? ls -Zl /usr/sbin/resolvconf /bin/resolvectl file /bin/resolvectl rpm -V systemd
Ah, interesting. I definitely need to be more factual then: this is actually not my system and I don't know if it's /usr/sbin/resolvconf or some other script. What I know: * A user reported SELinux errors related to openfortivpn appeared recently on Fedora 31. I believe this has been triggered by an upgrade from 1.11.0 to 1.12.0. * The main change between 1.11.0 and 1.12.0 is that openfortivpn now calls /usr/sbin/resolvconf. * The SELinux error message reports openfortivpn attempts to run bash but the only programs openfortivpn should attempt to execute on Fedora are: - /usr/sbin/pppd - resolvconf I'll investigate further...
It may be useful to turn on full auditing before reproducing again - please note path is not recorded by default. The following commands do the job: # to delete the implicit rule for not auditing auditctl -d never,task # to enable full path auditing auditctl -w /etc/shadow -p w -k shadow-write or create additional audit rules if it is not enough. Then reproduce the issue and collect the audit logs: ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts recent -ts recent means last 10 minutes. It is possible that e. g. some intermediate script is run apart from /usr/sbin/resolvconf.
I'll ask the user to run these commands. I guess it would be easier to install Fedora 31 in an virtual machine and test myself though. I am not aware of any script run directly by openfortivpn. What may happen is that pppd or even resolvconf run scripts, such as up/down scripts. Given that openfortivpn forks and execs pppd, do the SELinux error messages appear consistent?
Hi, user in question here. I turned on full audit logging as instructed and here is the output: ---- type=PROCTITLE msg=audit(03/12/2020 14:51:16.487:625) : proctitle=/bin/openfortivpn -c /var/lib/NetworkManager-fortisslvpn/edb0ff72-93c9-4346-909d-84a138476e60.config --no-routes --pppd-use-peer type=PATH msg=audit(03/12/2020 14:51:16.487:625) : item=0 name=/bin/sh inode=917654 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:shell_exec_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(03/12/2020 14:51:16.487:625) : cwd=/ type=SYSCALL msg=audit(03/12/2020 14:51:16.487:625) : arch=x86_64 syscall=execve success=no exit=EACCES(Permission denied) a0=0x7f191384e1ac a1=0x7ffdd2b97610 a2=0x560b6390b3a0 a3=0x8 items=1 ppid=5529 pid=80769 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=openfortivpn exe=/usr/bin/openfortivpn subj=system_u:system_r:openfortivpn_t:s0 key=(null) type=AVC msg=audit(03/12/2020 14:51:16.487:625) : avc: denied { execute } for pid=80769 comm=openfortivpn name=bash dev="dm-0" ino=917654 scontext=system_u:system_r:openfortivpn_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0 ---- type=PROCTITLE msg=audit(03/12/2020 14:51:23.533:627) : proctitle=/bin/openfortivpn -c /var/lib/NetworkManager-fortisslvpn/edb0ff72-93c9-4346-909d-84a138476e60.config --no-routes --pppd-use-peer type=PATH msg=audit(03/12/2020 14:51:23.533:627) : item=0 name=/bin/sh inode=917654 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:shell_exec_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(03/12/2020 14:51:23.533:627) : cwd=/ type=SYSCALL msg=audit(03/12/2020 14:51:23.533:627) : arch=x86_64 syscall=execve success=no exit=EACCES(Permission denied) a0=0x7ff217d861ac a1=0x7ff215568bd0 a2=0x55d89703f3a0 a3=0x8 items=1 ppid=80816 pid=80853 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=openfortivpn exe=/usr/bin/openfortivpn subj=system_u:system_r:openfortivpn_t:s0 key=(null) type=AVC msg=audit(03/12/2020 14:51:23.533:627) : avc: denied { execute } for pid=80853 comm=openfortivpn name=bash dev="dm-0" ino=917654 scontext=system_u:system_r:openfortivpn_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0 Perhaps worth noting is that I am not using `openfortivpn` directly, I'm using Gnome Network Manager for which there is a plugin for openfortivpn: https://github.com/GNOME/NetworkManager-fortisslvpn
For the sake of completeness, here are the other commands run by the user that show that resovlconf is indeed a link to an executable. My wrong, resolvconf is not a script. Hopefully the above data will help understand what happens here. $ ls -Zl /usr/sbin/resolvconf /bin/resolvectl -rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 132368 Feb 11 14:25 /bin/resolvectl* lrwxrwxrwx. 1 root root system_u:object_r:bin_t:s0 17 Feb 11 14:25 /usr/sbin/resolvconf -> ../bin/resolvectl* $ $ file /usr/sbin/resolvconf /bin/resolvectl /usr/sbin/resolvconf: symbolic link to ../bin/resolvectl /bin/resolvectl: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=e2ca6b6bf71575ae7482e67e124710b711436cfe, for GNU/Linux 3.2.0, stripped $ $ rpm -qf /usr/sbin/resolvconf systemd-243.7-1.fc31.x86_64 $ $ rpm -qf /bin/resolvectl systemd-243.7-1.fc31.x86_64 $
Which version of NetworkManager-fortisslvpn and openfortivpn are you running? rpm -q openfortivpn rpm -q fortisslvpn
Sorry. Should read: rpm -q openfortivpn rpm -q NetworkManager-fortisslvpn
Thank you for the commands output. There does not seem to be more useful information, we see just execution attempt to bash, the "--pppd-use-peer" fragment without the variable value etc. However, reading the openfortivpn(1) man page though, I spotted the following: Note that there may be other mechanisms to update /etc/resolv.conf, e.g., --pppd-use-peerdns in conjunction with an ip-up-script, This is handled by pppd (see pppd(8)), the scripts are located in /etc/ppp. I suggest to switch just the openfortivpn domain to permissive mode: semanage permissive -a openfortivpn_t <reproduce> semanage permissive -d openfortivpn_t <collect avc denials> You can also add audit watch rules for /etc/ppp, but it can give us too much of information.
Mario, it would help if you could provide the output of: rpm -q openfortivpn rpm -q NetworkManager-fortisslvpn We know NetworkManager-fortisslvpn is probably < 1.3.90-4 because it starts openfortivpn with: --pppd-use-peerdns=1 instead of more recent: --no-dns --pppd-use-peerdns=1 What happens then depends on the version of openfortivpn: * Before openfortivpn 1.12.0, /sbin/resolvconf is not called. * Starting with openfortivpn 1.12.O, /sbin/resolvconf is called (and breaks because resolvconf doesn't work on Fedora but that's another issue). If you give us the version of the above packages, we will know if /sbin/resolvconf may be called or not and this will give us an indication where to investigate.
Sorry for the delay from my side. rpm -q openfortivpn: openfortivpn-1.12.0-1.fc31.x86_64 rpm -q NetworkManager-fortisslvpn: NetworkManager-fortisslvpn-1.3.90-4.fc31.x86_64 I also tried following your instructions above (adding the openfortivpn domain to permissive mode). Then reproducing, it triggers no less than 14 SELinux alerts. I'm not sure about how to best report further on it as I don´t have much knowledge about SELinux at all and I'm only seeing all this because on Fedora 31 the SELinux Alert Browser GUI application sends notifications.
So you do have the latest versions: * openfortivpn >= 1.12.0 which calls /usr/sbin/resolvconf which is broken on fedora by default (but that's a different issue) * NetworkManager-fortisslvpn-1.3.90-4 >= which in principle should call openfortivpn with --pppd-use-peerdns=1 accordinng to this last commit before the release of NetworkManager-fortisslvpn-1.3.90-4 https://src.fedoraproject.org/rpms/NetworkManager-fortisslvpn/c/6378487 I have installed a vanilla and fully updated Fedora 31 in a virtual machine but am unable to reproduce the SELinux errors you experience. Yet SELinux is enabled and enforcing: $ sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 32 $ What I experience is that pppd is kind of broken by default on Fedora, like resolvconf, but that's a different issue: https://github.com/adrienverge/openfortivpn/issues/563#issuecomment-600528111
I am able to reproduce the SELinux error after installing NetworkManager-fortisslvpn and stating the VPN using the NetworkManager graphical user interface. I will now investigate how NetworkManager starts openfortivpn and why I cannot reproduce this issue from the command line - probably missing a specific option.
here is the error message reported by SETroubleshhot, same as initially reported: SELinux interdit à openfortivpn d'utiliser l'accès execute sur le fichier /usr/bin/bash. ***** Le greffon catchall (100. de confiance) suggère ********************* Si vous pensez que openfortivpn devrait être autorisé à accéder execute sur bash file par défaut. Alors vous devriez rapporter ceci en tant qu'anomalie. Vous pouvez générer un module de stratégie local pour autoriser cet accès. Faire autoriser cet accès pour le moment en exécutant : # ausearch -c "openfortivpn" --raw | audit2allow -M my-openfortivpn # semodule -X 300 -i my-openfortivpn.pp Informations complémentaires : Contexte source system_u:system_r:openfortivpn_t:s0 Contexte cible system_u:object_r:shell_exec_t:s0 Objets du contexte /usr/bin/bash [ file ] Source openfortivpn Chemin de la source openfortivpn Port <Inconnu> Hôte localhost.localdomain Paquets RPM source Paquets RPM cible bash-5.0.11-1.fc31.x86_64 SELinux Policy RPM selinux-policy-3.14.4-49.fc31.noarch Local Policy RPM selinux-policy-targeted-3.14.4-49.fc31.noarch Selinux activé True Type de stratégie targeted Mode strict Enforcing Nom de l'hôte localhost.localdomain Plateforme Linux localhost.localdomain 5.5.8-200.fc31.x86_64 #1 SMP Thu Mar 5 21:28:03 UTC 2020 x86_64 x86_64 Compteur d'alertes 4 Première alerte 2020-03-18 15:58:47 CET Dernière alerte 2020-03-18 16:33:00 CET ID local ea2abab2-a94a-4680-a7a4-a6326af19310 Messages d'audit bruts type=AVC msg=audit(1584545580.311:345): avc: denied { execute } for pid=2643 comm="openfortivpn" name="bash" dev="dm-0" ino=2558 scontext=system_u:system_r:openfortivpn_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0 Hash: openfortivpn,openfortivpn_t,shell_exec_t,file,execute
I had a look at how openfortivpn is started by NetworkManager-fortisslvpn. After starting the VPN from NetworkManger, I had a look at the options passed to openfortivpn: /bin/openfortivpn -c /var/lib/NetworkManager-fortisslvpn/8dd6b8bb-5deb-4de0-9e49-b423029cbc31.config --no-routes --pppd-use-peerdns=1 xxxxx.xxxx.de --pinentry /usr/libexec/nm-fortisslvpn-pinentry --pppd-plugin /usr/lib64/pppd/2.4.7/nm-fortisslvpn-pppd-plugin.so The configuration merely contains the username and password: $ sudo cat /var/lib/NetworkManager-fortisslvpn/8dd6b8bb-5deb-4de0-9e49-b423029cbc31.config username = xxxxxxx password = xxxxxxxxxxxx $ Therefore this should be equivalent to: /bin/openfortivpn -u xxxxxxxx --no-routes --pppd-use-peerdns=1 xxxxx.xxxx.de --pinentry /usr/libexec/nm-fortisslvpn-pinentry --pppd-plugin /usr/lib64/pppd/2.4.7/nm-fortisslvpn-pppd-plugin.so This raises no SELinux errors: /bin/openfortivpn -u xxxxxxxx --no-routes --pppd-use-peerdns=1 xxxxx.xxxx.de Therefore I suspect the SELinux errors are caused by the options specific to NetworkManager-fortisslvpn: --pinentry /usr/libexec/nm-fortisslvpn-pinentry --pppd-plugin /usr/lib64/pppd/2.4.7/nm-fortisslvpn-pppd-plugin.so But then I am at a loss how to debug that because I cannot use the exact same options from the command line. Probably missing some environment variables / Gnome dynamic libraries.
Is there any way we can add audit rules specific to /usr/libexec/nm-fortisslvpn-pinentry and /usr/lib64/pppd/2.4.7/nm-fortisslvpn-pppd-plugin.so?
*** Bug 1810880 has been marked as a duplicate of this bug. ***
*** Bug 1811414 has been marked as a duplicate of this bug. ***
Dmitri, If you are interested, you can try audit watch rules, e. g. auditctl -w /usr/libexec/nm-fortisslvpn-pinentry -p rw -k nmfortipin However, I've just submitted a PR to allow the shell execution: https://github.com/fedora-selinux/selinux-policy-contrib/pull/225
commit 2c38d3505ec6b7e5c267eb93a0d414e7c7ac47a7 (HEAD -> rawhide, origin/rawhide, origin/HEAD) Author: Zdenek Pytela <zpytela> Date: Wed Mar 25 11:39:03 2020 +0100 Allow openfortivpn exec shell Resolves:rhbz#1812812 Backported to F31 and F30
Before starting the VPN using NetworkManager-fortivpnssl I've run the command: sudo auditctl -w /usr/libexec/nm-fortisslvpn-pinentry -p rw -k nmfortipin The output in /var/log/audit/audit.log is: type=NETFILTER_CFG msg=audit(1585143644.656:393): table=raw family=2 entries=51 type=NETFILTER_CFG msg=audit(1585143644.658:394): table=mangle family=2 entries=65 type=NETFILTER_CFG msg=audit(1585143644.659:395): table=nat family=2 entries=102 type=NETFILTER_CFG msg=audit(1585143644.659:396): table=filter family=2 entries=187 type=NETFILTER_CFG msg=audit(1585143644.663:397): table=raw family=10 entries=53 type=NETFILTER_CFG msg=audit(1585143644.663:398): table=mangle family=10 entries=64 type=NETFILTER_CFG msg=audit(1585143644.663:399): table=nat family=10 entries=97 type=NETFILTER_CFG msg=audit(1585143644.663:400): table=filter family=10 entries=191 type=SERVICE_START msg=audit(1585143644.686:401): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset" type=AVC msg=audit(1585143644.767:402): avc: denied { execute } for pid=2867 comm="openfortivpn" name="bash" dev="dm-0" ino=2558 scontext=system_u:system_r:openfortivpn_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0 type=SERVICE_START msg=audit(1585143647.790:403): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbus-:1.9-org.fedoraproject.Setroubleshootd@5 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset" type=SERVICE_START msg=audit(1585143648.434:404): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbus-:1.9-org.fedoraproject.SetroubleshootPrivileged@4 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset" type=SERVICE_STOP msg=audit(1585143654.528:405): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset" type=SERVICE_STOP msg=audit(1585143658.417:406): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbus-:1.9-org.fedoraproject.Setroubleshootd@5 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset" type=SERVICE_STOP msg=audit(1585143658.766:407): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbus-:1.9-org.fedoraproject.SetroubleshootPrivileged@4 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
*** Bug 1818436 has been marked as a duplicate of this bug. ***
FEDORA-2020-6d33cc238c has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-6d33cc238c
FEDORA-2020-6d33cc238c has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-6d33cc238c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-6d33cc238c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-6d33cc238c has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.