On Mon, 9/22/08, Alan McKinnon <[EMAIL PROTECTED]> wrote:
> Bryan, you  may just have a rather good idea here and I
> find I'm in agreement.  SELinux is becoming more and more
> prevalent

I'm very Fedora and RHEL/CentOS-centric, so I have to keep
myself "in-check."  I know SELinux was a hot-topic back at
the Spring 2006 Advisory Meeting(s), but I didn't know how
prevalent it has become outside of the Red Hat world.

I believe I heard the next release of OpenSuSE is going to
enable it by default, but that -- of course -- does not
mean any included implementation is tested or working.  It
could just be the reference implementation, and enabler
"beware."

I would be less than objective to comment on Novell's future
course, and this aforementioned comment on OpenSuSE has no
bearing on the SLEx/NLx products.  But it does seem that
certain changes in Novell's approach to supporting AppArmor
may suggest they could be moving to add SELinux.  Again,
that's totally subjective/non-objective, and people like
Ross are in a far better position.

Hence why I commented and assumed that inclusion of SELinux
objectives is probably something left for the next revision
of the LPIC-1/LPIC-2 program, and based on more adoption
outside of just Fedora/RHEL-based releases.

> and at LPIC-2 level I think it correct that an admin
> knows their way around the basics. At the very least 
> they need to know how to switch it off <joke>, or how
> to avoid making things worse.
> As a point of reference, the RHCE coverage of this
> topic feels about right to me, I suspect you are
> thinking the same.

If you want to start looking at RHCE, I'd suggest
you break it down sort of like ...
  RH133 (RHCT) SELinux content -> LPIC-1 consideration
  RH253 (RHCE) SELinux content -> LPIC-2 consideration
  RH429 (RHCSS) SELinux content -> LPIC-3 Security

Even RHCTs have to be aware on how to enable v. disable,
set enforcing (targeted) v. permissive, etc...  That's
still in the content, even though RHCT focuses on local
System Administration, not services configuration.

The RHCE doesn't go too much beyond that, focuses on
basic contexts, listing, restoring and even applying
new ones for non-standard objects, etc...  In a nutshell,
if it applies to standard services that Red Hat supports
on the RHEL product with SLAs, you have to know how to
ensure SELinux is enabled (targeted) and enforcing.

[ For those unaware, it is quite possible to score a 0%
on the 3-hour, 2nd part of the RHCE if you foul up
this basic SELinux configuration. ]

Ignoring RHS333 (RHCA/RHCSS), the RHS429 (RHCSS) then
goes into rule writing and targetting applictions,
clearly advanced Security Concepts (not general
junior or senior administration).

THE QUESTION is, how much do we put into LPIC-1/2/3?

THE ANSWER is actually easier than you think.

SELinux Security Contexts are Extended Attributes (EAs)
aka "xattr".  When you cover xattrs, then add the
possible question on a SELinux Security Context.  I.e.,
for ls, the "-Z" option.  E.g., give the output when
the -Z option is thrown, and make users pick (from a
list) what attributes are being shown.  Just an example.

So for LPIC-1, it could be simple identity, such as in the
aforementioned ls output example.  It is also good to know
the three (3) different levels (Red Hat only does 2 --
Fedora Core 2 originally did all 3, but Red Hat backed off
from that in Fedora Core 3, which RHEL 4 is based on).

For LPIC-2, you start introducing the ultra-basic utilities
to restore contexts, apply an existing context to a new,
non-standard file that the reference implementation doesn't
know about, but is already a known and protected context,
etc...  So maybe that's where LPIC-2 is "like" RHCE, with
exception of a few details (especially RHCE-centric).

For LPIC-3, don't know.  How deep do we want to go?  Red
Hat dedicates an entire, 4 hour (or so) lab exam in EX429 to
just SELinux.  A better consideration might be what they
cover in EX333, which covers Security in general (I don't
know how much beyond RHCE).  It's really hard to cram in
a lot of SELinux because there's so much to security.

Maybe we just shift what I said above about RHCT basics 
going into LPIC-1 more to LPIC-2, and most of the RHCE-level
SELinux from LPIC-2 to more of the LPIC-3 Security objectives,
possibly with a little more troubleshooting (e.g., identifying
what context to apply on what file from audit output).

I leave it to others with more experience in designating the
levels to decide.  But I'm glad both you and I agree Alan,
SELinux -- MAC/RBAC (Mandatory/Role Based Access Controls)
cannot be ignored on a basic Linux Certification exam in the
coming future.  It's taking over enterprises.

_______________________________________________
lpi-examdev mailing list
[email protected]
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev

Reply via email to