<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" ><div><span style="font-family:Verdana,Geneva,sans-serif;" >Hi All,</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >(My apologies for the lengthy email.)</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >Below are few use-cases in BMC, which i feel inclusion of SELinux would be a value add (there could be may more missing). Please feel free to drop-in your comments/feedback.</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >1. BMC every application runs a root (tops the security wish-list)<br>========================================</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >Assume that a malicious user compromises an application, say for example "bmcweb". The user found a loophole in the webgui, and plants a php script through which he can add a user with root privilege. This makes things easy as bmcweb is running as root (and has sufficient rights to do it), which could result in sniffing or potentially could bring the server down.</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >- With SELinux, we can stop bmcweb from adding another user with root privilege, even when running as root. We should write a policy , so that bmcweb gets an access denied when trying to edit /etc/passwd file.</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >Another classic example of udev, where software must typically run as the root user to write into raw block devices. In a traditional DAC-based Linux environment, if the root user becomes compromised, that user can write to every raw block device. However, SELinux can be used to label these devices so the process assigned the root privilege can write to only those specified in the associated policy.</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >For example, IBM uses nbd to offload the dumps to management console, as per the udev rule mentioned any root user can write to the network block device, say an application which is running as root(bmcweb/ipmi) was compromised and it starts writing into the device , there by keeping it busy (because of which pldm cannot write into the device , because of which hypervisor dumps cannot be offloaded)</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >2. Every application trusts every other running on the BMC system<br>=========================================</span></div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >Assume there is a weak code in ipmi, which got exploited and it tries to delete bmcweb_persistence.json (which contains the sessions x-auth token details and other confidential information).</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >- bmcweb_persistence.json will be loaded into bmcweb whenever it restarts, so that the sessions can be still valid even when bmcweb is crashed due to some reason.</span></div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >- In the current state, no one can prevent compromised ipmi from deleting the file that bmcweb requires, with SELinux (using type enforcement mode), we can prevent ipmi from executing (or even stat on) bmcweb files.</span></div>
<div><br><span style="font-family:Verdana,Geneva,sans-serif;" >3. We use SYSTEMD - We have SELINUX SYSTEMD ACCESS CONTROL<br>===========================================</span></div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >As we know systemd starts and stops all services, and users and processes communicate with systemd using the systemctl utility. The systemd daemon has the ability to consult the SELinux policy and check the label of the calling process and the label of the unit file that the caller tries to manage, and then get it validated from SELinux whether or not the caller is allowed to access.</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >This approach strengthens access control to critical system capabilities, which include starting and stopping system services.</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >- Assume that a compromised ipmi running as root stops the bmcweb/network service, this would bring down the webserver/network. With SELinux, we can have a fine grained control policy to only allow ipmi to query the status of bmcweb, but cannot enable or disable the service.</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >4. We use JOURNALD - We have SELINUX JOURNALD ACCESS CONTROL<br>============================================</span></div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >Say ipmid is compromised (it can be blocked from malfunctioning), but it also sends syslog messages, SELinux would allow the compromised process to continue to send those messages.</span></div>
<div><br><span style="font-family:Verdana,Geneva,sans-serif;" >The compromised ipmid could format syslog messages to match other daemons and potentially mislead an administrator, or even worse, a utility that reads the syslog file into compromising the whole system.</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >- The systemd-journal daemon verifies all log messages and, among other things, adds SELinux labels to them. It is then easy to detect inconsistencies in log messages and prevent an attack of this type before it occurs.</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >5.1 Port Security using SELinux<br>===============================</span></div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >Using SELinux , It is possible to limit TCP port access to specific scripts/applications and block other applications from using them.</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >- For example, bmcweb works on tcp port 443, what if another application which gets started before bmcweb acquires the same port and which causes the bmcweb to fail acquiring the port.Using SELinux, we can label a process/application to a use a particular port.</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >5.2 Controlling service acquisition with SELinux<br>==============================</span></div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >Administrators can enable within D-Bus to ensure that only well-established domains can acquire a particular object within D-Bus.<br> </span></div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >- Without this control, malicious code could register itself as being xyz.openbmc_project.Network, for instance, and pretend to be network system daemon on the bus. Other applications might mistakenly send out sensitive information to the application.</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >6. Governing DBus message flows - Hardening the DBUS Communication<br>==============================================</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >Another control that D-Bus validates is which applications are allowed to communicate with each other. This is not configurable through the service configurations, but is a pure SELinux policy control.</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >- Whenever a source application is calling a method of a target application, D-Bus validates the send_msg permission between the two domains associated with the source and target applications and if these permissions are not in effect, then D-Bus will not allow the communication to happen.</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >- There by this selinux feature would restrict the ability of the dbus applications to sniff the exposed interfaces of the other applications, even when they are running as root.</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >7. Confining Linux Users abilities using SELinux<br>==================================================</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >Users are mapped to the SELinux unconfined_u user by default and all processes that are run by unconfined_u are in the unconfined_t domain. This means that users can access across the system within the limits of the standard Linux DAC policy.</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >- However, a number of confined SELinux users are available in linux. This means that users can be restricted to limited set of capabilities. Each Linux user is mapped to an SELinux user using a policy, allowing Linux users to inherit the restrictions placed on SELinux users, for  example (depending on the user),<br>we can restrict the user from :<br> -  using networking<br> -  run setuid applications (unless SELinux policy permits it)<br> -  run the su and sudo commands.</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >When user logs-in, the pam_selinux module maps the Linux user to an SELinux user , and sets up the resulting SELinux context. By using this feature, we can restrict the permissions of even a root user by his login method.</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >For Example:<br>========<br>- By leveraging this feature, root logged-in via webserver will get only limited permissions , but the same root user logged in via ssh will get full permission.</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >8. Disable ptrace()<br>=============</span></div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >The ptrace() system call allows one process to observe and control the execution of another process and change its memory and registers. This call is used primarily by developers during debugging, for example when using the strace utility. When ptrace() is not needed, it can be disabled to improve system security.</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >- With Selinux, we can disable ptrace() , which denies all processes, even those that are running in unconfined_t domains from being able to use ptrace() on other processes</span></div>
<div> </div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >9. Restricting on users capabilities for executing applications<br>=====================================</span></div>
<div><span style="font-family:Verdana,Geneva,sans-serif;" >-  Not allowing Linux users to execute applications (which inherit users' permissions) in their home directories and the /tmp directory, which they have write access to, helps prevent flawed or malicious applications((memory leaked)) from modifying files that users own/corrupt the system.</span></div>
<div><br><span style="font-family:Verdana,Geneva,sans-serif;" >Regards,<br>Manoj</span></div>
<div> </div></div></div></div><BR>