Training for Writing SELinux Policy

[Fong Vang]

Which training classes are best for hands-on experience writing SELinux policies?  Any
recommendations?  Preferably offsite for a week.

[thomas cameron]

On 05/26/2016 07:35 PM, sudoyang(a)gmail.com 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.

[Tracy Reed]

On Fri, May 27, 2016 at 08:04:35AM PDT, Thomas Cameron spake thusly:
>  On 05/26/2016 07:35 PM, sudoyang(a)gmail.com 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.

-- 
Tracy Reed

[Marko Rauhamaa]

Tracy Reed <treed(a)ultraviolet.org&gt;:

>  On Fri, May 27, 2016 at 08:04:35AM PDT, Thomas Cameron spake thusly:
> > On 05/26/2016 07:35 PM, sudoyang(a)gmail.com 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

[Ted Toth]

Tresys might offer training.

On Thu, May 26, 2016 at 7:35 PM,  <sudoyang(a)gmail.com&gt; wrote:
> Which training classes are best for hands-on experience writing SELinux policies? 
Any recommendations?  Preferably offsite for a week.
> --
> selinux mailing list
> selinux(a)lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/[e-mail]

[thomas cameron]

On 05/29/2016 03:28 AM, Tracy Reed wrote:
>  On Fri, May 27, 2016 at 08:04:35AM PDT, Thomas Cameron spake thusly:
> > On 05/26/2016 07:35 PM, sudoyang(a)gmail.com 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. 

We're very serious about SELinux. There has simply not been enough
consistent demand for advanced policy courses to justify the
development, translation, and QA cycles for those courses.

If you're interested in such a course, please contact Red Hat sales
(https://www.redhat.com/en/contact-us) for your local sales contact.

Thomas

[Fong Vang]

They only have a two day course.  Looks like 1/2 of the training (1 day) is
devoted to SELinux intro so only one day for writing policy.  Is this
really enough?

On Sun, May 29, 2016 at 7:55 AM Ted Toth <txtoth(a)gmail.com&gt; wrote:

>  Tresys might offer training.
>
>  On Thu, May 26, 2016 at 7:35 PM,  <sudoyang(a)gmail.com&gt; wrote:
>  > Which training classes are best for hands-on experience writing SELinux
>  policies?  Any recommendations?  Preferably offsite for a week.
>  > --
>  > selinux mailing list
>  > selinux(a)lists.fedoraproject.org
>  >
>  https://lists.fedoraproject.org/admin/lists/[e-mail]
>