220 likes | 535 Views
Security Enhanced Linux (SELinux). UCBU Platform Team. Agenda. Introduction to SELinux Benefits of SELinux Use of SELinux as an alternative to CSA Issues & Concerns How SELinux works – An example. CLI to control SELinux Troubleshooting tips Actions affected by SELinux Reference
E N D
Security Enhanced Linux (SELinux) UCBU Platform Team
Agenda • Introduction to SELinux • Benefits of SELinux • Use of SELinux as an alternative to CSA • Issues & Concerns • How SELinux works – An example. • CLI to control SELinux • Troubleshooting tips • Actions affected by SELinux • Reference • Questions
Introduction to SELinux SELinux is the integrated security enhancement to the Linux operating system. • SELinux is integrated with RHEL as a standard feature. • No additional cost. • Linux has 2 forms of access control : • Discretionary Access Control (DAC) – In Linux, the owner-group-world permission mode. • Mandatory Access Control (MAC) – SELinux, the security enhancement to Linux, implements a flexible form of MAC called type enforcement. Both standard Linux (DAC) and SELinux (MAC) access controls must be satisfied to access an object. • SELinux uses policies (like CSA) to refer to the set of rules that are loaded into the kernel for access enforcement. SELinux comes with default base policies we can augment to implement CUC specific security policies. • SELinux is packaged as a set of rpms (selinux-policy-devel, libselinux, selinux-policy, policycoreutils), and on a stock RHEL 5 install will get deployed as policy files.
Benefits of SELinux • Test Coverage • RedHat has a rigorous test suite for its RHEL releases. • Large user community: RHEL users, Fedora community. • Performance • SELinux is enabled during RedHat’s performance testing, and with base policies, overhead is about 5%. • This overhead is, of course, workload dependent, and we will need to do performance testing with SELinux policies for CUC to compare with CSA. • These numbers shall be updated once the performance testing is complete prior to FCS. • Upgrade • Since SELinux is integrated with RHEL as a standard feature, there would be no problem in moving to newer RHEL releases. • Policies are backward compatible. • Even for minor RHEL upgrades, sometimes a development cycle is needed for CSA. This would not be necessary for SELinux implementation.
Benefits of SELinux (contd.) • Support • Kernel based problems can immediately be escalated to RedHat. (Currently, these have to be reproduced without CSA, before opening a case with RedHat). • No extra royalty or license fee • Integrated into RHEL.
SELinux as an alternative to CSA SELinux is also a stable and mature technology. It has been in the mainline Linux kernel since 2003, and included in RedHat Enterprise Linux 4 (2005). It is proven technology, used widely in the IT industry. * Connection Rate Limit and Network Shield protection is now provided by IPTables
SELinux as an alternative to CSA (contd.) • SELinux can be changed to “permissive” mode using CLI. Completely disabling it requires root / remote account access. • Changing SELinux mode to “permissive” does not require a reboot, but disabling it via root access does.
How SELinux works – An Example • SELinux (in enforcing mode) locks down the whole system and policies have to be written to open up segments of the system for each application / process. • By default, with SELinux in strict mode, a root user cannot open up a secure shell to login to a server. • DAC permissions allow the root user to invoke ssh. • -rwxr-xr-x 1 root root 312672 Jun 23 01:09 ssh • MAC permissions , by default, do not allow the root user to invoke ssh. • -rwxr-xr-x root root system_u:object_r:ssh_exec_t ssh • The base SELinux policy needs to be modified to allow the root user to transition to a role and type that allow ssh to be executed by root. • allow sshd_t sysadm_t:process { siginh transition noatsecure }; • With this change to the base policy,a root user can open up a secure shell to login to a server.
Command Line Interface (CLI) Four new SELinux related CLI commands are created “utils os secure status” – output current SELinux status “utils os secure enforce” – change current mode to “Enforcing”, no reboot is required. “utils os secure permissive” – change current mode to “Permissive”, no reboot is required. “utils create report security” – collect all SELinux related files for troubleshooting. The audit logs which can be collected using the CLI command “utils create report security” can provide information on blockings due to SELinux.
Troubleshooting tips Special commands for remote account user, reboot is required to take effect. /usr/local/platform/bin/controlsel enable – allow remote account user to enable SELinux /usr/local/platform/bin/controlsel disable – allow remote account user to disable SELinux completely. The above commands can be used to turn SELinux off and on. In the field, when issues are encountered with regards to SELinux, it can be disabled temporarily. We have seen cases where SELinux behaves differently in “permissive” mode when compared with “disabled” mode.
SELinux “permissive” and “disabled” modes Disabling SELinux means SELinux is completely switched off in the kernel. This allows all operations to be permitted, and also disables the process which decides what to label files & processes with. Disabling SELinux could lead to problems if you want to re-enable it again later. If you disable SELinux completely, new files and directories are created without a security context, and if you ever want to turn SELinux back on, you will have to re-label the file system. The difference between permissive and disabled modes is that in permissive mode, the kernel logs policy violations and labels new files with the appropriate security context. Note: When SELinux is re-enabled using “/usr/local/platform/bin/controlsel enable”, and the system rebooted, the files in the system shall automatically get relabeled.
Troubleshooting tips (contd) Denial messages in syslog/messages file: Jan 25 12:40:32 sw075b-pub user 6 setroubleshoot: SELinux is preventing ipprefs (snmpd_t) "append" to ./ipprefs.conf (cisco_etc_t). For complete SELinux messages. run sealert -l 19402a85-2c74-4483-a771-d20f05b745cd Equivalent denial message in audit log: type=AVC msg=audit(1295981046.918:95246): avc: denied { append } for pid=31664 comm="ipprefs" name="ipprefs.conf" dev=cciss/c0d0p2 ino=2950555 scontext=system_u:system_r:snmpd_t:s0 tcontext=system_u:object_r:cisco_etc_t:s0 tclass=file Note: TAC can check the syslog/message file for any SELinux blocking. Audit logs are more useful for troubleshooting the problem.
Troubleshooting tips (contd) Log message for Connection Rate Limit rule in syslog/messages file: Jan 19 16:03:38 sw075b-sub kern 4 kernel: Exceeded hashlimit IN=eth0 OUT= MAC=00:16:35:6a:31:71:00:0b:cd:41:ae:08:08:00 SRC=10.8.52.253 DST=10.8.52.61 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=23811 PROTO=TCP SPT=4544 DPT=22 WINDOW=512 RES=0x00 SYN URGP=0 This log suggests that the rate of connections on port 22 exceeds the normal rate. The SRC IP can be further investigated to check if the traffic is valid.
Troubleshooting tips (contd) If you suspect SELinux is the root cause for an issue, please isolate it to SELinux in the following manner – Step 1: 1. Issue CLI command “utilsos secure permissive”. 2. Reproduce the issue. If the issue exists even when SELinux is in permissive mode, then go to step 2 to further isolate the issue. If the issue disappears when SELinux is in permissive mode, then it is a SELinux policy issue. In this case, collect the SELinux diagnostics file using CLI command “utils create report security”
Troubleshooting tips (contd) Step 2: • 1.Run /usr/local/platform/bin/controlsel disable. And say 'yes' when it prompts for reboot. • 2. Reboot • 3. Reproduce the issue If the issue exists even when SELinux is in disabled mode, then the issue is not related to SELinux. If the issue disappears when SELinux is in disabled mode, then it is a SELinux driver or policy issue – please collect the logs and bring it up with the SELinux development team on the ucbu-cuc-platform(mailer list). It was a decision by Product Marketing that we only allow the change in SELinux mode to “permissive” through CLI, rather than disabling it. Additionally, disabling SELinux requires a reboot, whereas changing it to “permissive” does not.
Actions affected by SELinux Fresh install (post install takes about 8-10 minutes longer) L2 and RU (switch version takes longer) Startup after drf restore (first reboot after drf restore takes longer) Following CLI commands’ execution takes longer: utils remote_account create set account name Changing port value for a service takes longer (when the current port is registered with SELinux, then the semanage command is run to update the corresponding port context. Each semanage command takes around 30s) Changing the mode of SELinux from disable to enable requires a reboot, which takes 5 minutes longer that a normal reboot. Note: The time taken may vary depending on server model.
Actions affected by SELinux (contd.) Future upgrades, where “from” and “to” support SELinux shall also take longer, until we upgrade to RHEL 6. The reason for this delay is the “semanage” command which is used to set the security contexts on ports and users. Each port / user requires the execution of one “semanage” command. In RHEL 6, the “semanage” command can be used on groups of ports / users and hence will not require as much time.
Reference For Connection SELinux mailer: ucbu-cuc-platform Twiki: http://zed.cisco.com/confluence/display/WIN/CSA+Replacement+-+SELinux+Development http://zed.cisco.com/confluence/display/CUC/Unity+Connection+-+SELinux