Tracy Reed <treed@xxxxxxxxxxxxxxx>: > On Fri, May 27, 2016 at 08:04:35AM PDT, Thomas Cameron spake thusly: >> On 05/26/2016 07:35 PM, sudoyang@xxxxxxxxx wrote: >> > Which training classes are best for hands-on experience writing >> > SELinux policies? Any recommendations? Preferably offsite for a >> > week. >> >> I don't know of any. Red Hat used to do RHS429, but it has not been >> updated since RHEL 5, and I don't know of anyone still offering it. > > It make one wonder how serious they are about the future of SELinux. SELinux as an approach seems unworkable, or at least not worked out yet. We have at least these roles or target audiences for SELinux: * end users * system administrators * software developers * Linux vendors Introductory SELinux materials are available but don't make clear who should be doing and what wrt SELinux. Maybe the end users shouldn't concern themselves with SELinux because they wouldn't likely be entitled to create holes in the security policies. However, since a good many Linux end users are also system administrators of their boxes, the distinction may be difficult to maintain. Should the system administrator then be tweaking with the policies? Should they be creating policies? Should they only set booleans? Should they add to the set of booleans? What methodology should the system administrator use to specify a robust SELinux policy? Should the admin invent a set of ten SELinux labels, would one new label be enough, or should they ride on the predefined labels? How could a system administrator know what valid access needs a piece of software has? After all, most software developers ignore SElinux and won't bother publishing a complete access requirement specification. Should the software developer ship the product with SELinux policies? Should the policies be designed separately for each distro? What best practices are documented for the developers? What tools must the target platform have installed to be able to integrate the third-party policy with the default policy set? How do system administrators and software developers make sure their policies survive operating system updates and upgrades? RedHat has been promoting SELinux and seems to have taken an approach that the end users, system administrators and software developers don't have to understand much of SELinux. RedHat will hold the knowledge: * RedHat has come up with a set of default policies and booleans. Others should not think of touching those. This situation is analogous with the firewall. * RedHat assumes their customers mostly use Linux to run one or more of the services that come with the distro. RedHat has no answer to the SELinux needs of third-party software. * Every now and then, SELinux prevents proper functioning of a system. Since the system administrator is unequipped to properly analyze and correct the situation, most simply cut the Gordian knot and move on. Deep down, I'm afraid that the problem is fundamentally intractable. You cannot teach a system administrator three simple principles of SELinux to cover all software that gets installed on a system. Every piece of software is unique. Every installation is unique. The best approach offered to system administrators is to keep watching the audit log and keep adding empirical exceptions to the policies as the software runs into access violations. If the problem set is to have a solution, it needs to be started with the methodology for software developers. Every software developer understands the proper principles of starting up a Linux service (<URL: http://www.microhowto.info/howto/cause_a_process_to_become_a_daemon.html>). Those principles are currently being amended by the requirements of systemd; the systemd integration of a daemon shouldn't concern the sysadmin or the distro maker -- it should be the responsibility of the software developer. Analogously, it should be the software developer's responsibility to ensure the robust integration with SELinux. For that, the SELinux gods need to come up with a cookbook for developers. Maybe Linux will follow the lead of the mobile software platforms and enclose each "app" in a container. While very limited, that simplistic approach would be easy to understand and get right. It would also probably remove the need for SELinux altogether. Marko Software developer -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/selinux@xxxxxxxxxxxxxxxxxxxxxxx
