 |
FD.io VPP
v20.09-64-g4f7b92f0a
Vector Packet Processing
|
|
FD.io VPP
v20.09-64-g4f7b92f0a
Vector Packet Processing
|
Security-enhanced Linux (SELinux) is a security feature in the Linux kernel. At a very high level, SELinux implements mandatory access controls (MAC), as opposed to discretionary access control (DAC) implemented in standard Linux. MAC defines how processes can interact with other system components (Files, Directories, Other Processes, Pipes, Sockets, Network Ports). Each system component is assigned a label, and then the SELinux Policy defines which labels and which actions on each label a process is able to perform. The VPP Custom SELinux Policy defines the actions VPP is allowed to perform on which labels.
The VPP Custom SELinux Policy is intended to be installed on RPM based platforms (tested on CentOS 7 and RHEL 7). Though SELinux can run on Debian platforms, it typically is not and therefore is not currently being built for Debian.
The VPP Custom SELinux Policy does not enable or disable SELinux, only allows VPP to run when SELinux is enabled. A fresh install of either Fedora, CentOS or RHEL will have SELinux enabled by default. To determine if SELinux is enabled on a given system and enable it if needed, run:
To make the change persistent, modify the following file to set SELINUX=enforcing:
To install VPP, see the installation instructions on the VPP Wiki (https://wiki.fd.io/view/VPP/Installing_VPP_binaries_from_packages). The VPP Custom SELinux Policy is packaged in its own RPM starting in 18.04, vpp-selinux-policy-<VERSION>-<RELEASE>.rpm. It is packaged and installed along with the other VPP RPMs.
If VPP has never been installed on a system, then starting in 18.04, the VPP Custom SELinux Policy will be installed with the other RPMs and all the system components managed by VPP will be labeled properly.
In the case where the VPP Custom Policy is being installed for the first time, either because VPP has been upgraded or packages were removed and then reinstalled, several directories and files will not not be properly labeled. The labels on these files will need to be fixed for VPP to run properly with SELinux enabled. After the VPP Custom SELinux Policy is installed, run the following commands to fix the labels. If VPP is already running, make sure to restart VPP after the labels are fixed. This change is persistent for the life of the file. Once the VPP Custom Policy is installed on the system, subsequent files created by VPP will be labeled properly. This is only to fix files created by VPP prior to the VPP Custom Policy being installed.
NOTE: Because the VPP APIs allow custom filenames in certain scenarios, the above commands may not handle all files. Inspect your system and correct any files that are mislabeled. For example, to verify all VPP files in /tmp/ are labeled properly, run:
Any files not properly labeled with vpp_tmp_t, run:
Documentation in the VPP Wiki (https://wiki.fd.io/view/VPP/) and doxygen generated documentation have examples with files located in certain directories. Some of the recommend file locations have been moved to satisfy SELinux. Most of the documentation has been updated, but links to older documentation still exist and there may have been instances that were missed. Use the file locations described below to allow SELinux to properly label the given files.
File locations that have changed:
The VPP Debug CLI, vppctl, allows a sequence of CLI commands to be read from a file and executed. To avoid from having to grant VPP access to all of /tmp/ and possibly /home/ sub-directories, it is recommended that any VPP Debug CLI script files be placed in a common directory such as /usr/share/vpp/.
For example:
To execute:
Or
If the file is not labeled properly, you will see something similar to:
Some of the original documentation showed script files being executed out of /tmp/. Convenience also may lead to script files being placed in /home/<user>/ subdirectories. If a file is generated by the VPP process in /tmp/, for example a trace file or pcap file, it will get properly labeled with the SELinux label vpp_tmp_t. When a file is created, unless a rule is in place for the process that created it, the file will inherit the SELinux label of the parent directory. So if a user creates a file themselves in /tmp/, it will get the SELinux label tmp_t, which VPP does not have permission to access. Therefore it is recommended that script files are located as described above.
vHost sockets are created from VPP perspective in either Server or Client mode. In Server mode, the socket name is provided to VPP and VPP creates the socket. In Client mode, the socket name is provided to VPP and the hypervisor creates the socket. In order for VPP and hypervisor to share the socket resource with SELinux enabled, a rule in the VPP Custom SELinux Policy has been added. This rules allows processes with the svirt_t label (the hypervisor) to access sockets with the vpp_var_run_t label. As such, when SELinux is enabled, vHost sockets should be created in the directory /var/run/vpp/.
Some of the original documentation showed vHost sockets being created in the directory /tmp/. To work properly with SELinux enabled, vHost sockets should be created as described above.
The VPP log file location is set by updating the /etc/vpp/startup.conf file:
By moving the log file to /var/log/vpp/, it will get the label vpp_log_t, which indicates that the files are log files so they benefit from the associated rules (for example granting rights to logrotate so that it can manipulate them).
The default startup.conf file creates the VPP log file in /tmp/vpp.log. By leaving the log file in /tmp/, it will get the label vpp_tmp_t. Moving it to /var/log/vpp/, it will get the label vpp_log_t.
VPP installs multiple files on the system. Some files have fixed directory and file names:
Others files have default directory and file names but the default can be overwritten:
/usr/lib/systemd/system/vpp.service file by changing the -c option on the VPP command line:/etc/vpp/startup.conf file by changing the cli-listen setting:/etc/vpp/startup.conf file by changing the log setting:If the directory of any VPP installed files is changed from the default, ensure that the proper SELiunx label is applied. The SELinux label can be determined by passing the -Z option to many common Linux commands:
The following SELinux types are created by the VPP Custom SELinux Policy:
vpp_t - Applied to:vpp_config_rw_t - Applied to:/etc/vpp/*vpp_tmp_t - Applied to:/tmp/*vpp_exec_t - Applied to:/usr/bin/*vpp_lib_t - Applied to:/usr/lib/vpp_api_test_plugins/*/usr/lib/vpp_plugins/*vpp_unit_file_t - Applied to:/usr/lib/systemd/system/vpp.*vpp_log_t - Applied to:/var/log/vpp/*vpp_var_run_t - Applied to:/var/run/vpp/*If SELinux issues are suspected, there are a few steps that can be taken to debug the issue. This section provides a few pointers on on those steps. Any SELinux JIRAs will need this information to properly address the issue.
First, install the SELinux troubleshooting packages:
To enable proper logging, restart auditd:
While debugging issues, it is best to set SELinux to Permissive mode. In Permissive mode, SELinux will still detect and flag errors, but will allow processes to continue normal operation. This allows multiple errors to be collected at once as opposed to breaking on each individual error. To set SELinux to Permissive mode (until next reboot or it is set back), use:
After debugging, to set SELinux back to Enforcing mode, use:
Once the SELinux troubleshooting packages are installed, perform the actions that are suspected to be blocked by SELinux. Either tail the log during these actions or grep the log for additional SELinux logs:
Below are some examples of SELinux logs that are generated:
From the logs above, there are two sets of commands that are recommended to be run. The first is to run the sealert command. The second is to run the ausearch | audit2allow commands and the semodule command.
This sealert command provides a more detailed output for the given issue detected.
In general, this command pumps out too much info and is only needed for additional debugging for tougher issues. Also note that once the process being tested is restarted, this command loses it's context and will not provide any information:
These set of commands are more useful for basic debugging. The ausearch | audit2allow commands generate a set files. It may be worthwhile to run the commands in a temporary subdirectory:
As shown above, the file my-vpp.te has been generated. This file shows possible changes to the SELinux policy that may fix the issue. If an SELinux policy was being created from scratch, this policy could be applied using the semodule -i my-vpp.pp command. HOWEVER, VPP already has a policy in place. So these changes need to be incorporated into the existing policy. The VPP SELinux policy is located in the following files:
In this example, map needs to be added to the packet_socket class. If the vpp-custom.te is examined (prior to this fix), then one would see that the packet_socket class is already defined and just needs to be updated:
Before blindly applying the changes proposed by the ausearch | audit2allow commands, try to determine what is being allowed by the policy and determine if this is desired, or if the code can be reworked to no longer require the suggested permission. In the my-vpp.te file from above, it is suggested to allow vpp_t (i.e. the VPP process) access to all files in the home directory (allow vpp_t user_home_t:file { open read };). This was because a vppctl exec command was executed calling a script located in the /home/<user>/ directory. Once this script was run from the /usr/share/vpp/ directory as described in a section above, these permissions were no longer needed.
1.8.13