Bug 118577

Just a couple of small corrections:

## This warning is not necessary, since this is the FC release notes
(I know this was inserted for the RHEL relnotes, where it made sense):

"SELinux mailing list ââ¬â fedora-selinux-list (So named
because the majority of advanced SELinux development at Red Hat takes
place as part of the Fedora Project; however, Fedora Core users with
SELinux-related questions and comments are welcome.)"

## Extra < showed up here:

Q:. What is SELinux policy?
A:. The SELinux policy describes the access permissions ... Fedora
Core policy is delivered in policy-sources-<<version>-<arch>.rpm.

## A slip of the finger, and I made the "Z" into a "z" - "-Z" should
be capitalized in all cases:

A:. The new -Z option is the short method for displaying the context
of a subject or object:

ls -alz <file-name> --> ls -alZ <file-name>
id -z               --> id -Z 
ps -eZ              --> correct as-is   

## I think it would be a good idea to mention where the SELinux mode
is set during install, i.e., in the firewall configuration screen.  I
notice that you did not mention this; I defer to your judgement, but
wanted to make sure you didn't miss this.  Here is an example change:

"SELinux in Fedora Core defaults to enforcing mode.  During
installation, you can choose which mode SELinux is configured to start
under in the firewall configuration screen."

## Please update the link to HOWTO start writing policy with this
friendlier URL:

### Change:

The UnOfficial FAQ has some generic policy writing HOWTO information
(http://sourceforge.net/docman/display_doc.php?docid=14882&group_id=21266#BSP.1)
http://www.crypt.gen.nz/selinux/faq.html#BSP.1

### to read:

The UnOfficial FAQ has some generic policy writing HOWTO information 
(http://www.crypt.gen.nz/selinux/faq.html#BSP.1).

## The path '/usr/bin/audit2allow' is spurious; I have no actual clue
what the path is.  If we don't come up with an answer, I recommend we
drop the full path.  It should be in the $PATH for an SELinux install,
I suppose.

# This may be old-news by now; I'll try to get a definitive answer so
   we can remove this comment; no need to mention past kernel bugs. :)

Q:. Can I test NFSv4?
A:. To do this, you must boot with selinux=0. There is a bug in this
alpha release of the kernel that prevents NFSv4 from running on an
SELinux-enabled system. To run NFSv4, you must disable SELinux.

## 30

/usr/bin/audit2allow is correct.

I suggest not mentioning SIDs in the FAQ.  In 2.6.x SIDs are only used
internally in the kernel, anyone who is not going kernel coding has no
need to know about them.

Mention that if you boot with "selinux=0" then any files you create
will not have SE Linux context information and you may need to relabel
your entire system next time you boot into SE Linux.

I just saw IRC discussion about possible consequences of losing
context info with 'selinux=0'.  For example, if your initscripts lose
their context, and you try to boot with 'selinux=1', you won't get
very far.

Considering this, I recommend that we add a BIG WARNING about setting
'selinux=0'.  This seems like a good place to suggest
SELINUX=disabled, as well. 

      <qandaentry>
        <question>
          <para>
            How do I turn &SEL; off at boot?
          </para>
        </question>
        <answer>
          <para>
            Add <option>selinux=0</option> to your kernel command line.
          </para>
          <warning>
            <title>Warning</title>
            <para>
              Be very careful using this option.  If you boot with
              <option>selinux=0</option>, any files you create will
              not have &SEL; context information.  At the least you
              may need to relabel the file system, and it's possible
              you will be unable to boot with
              <option>selinux=1</option>.
            </para>
            <para>
              As an alternative to <option>selinux=0</option>, try
              using <computeroutput>SELINUX=disabled</computeroutput>
              in <filename>/etc/sysconfig/selinux</filename>.
            </para>
          </warning>
        </answer>
      </qandaentry>

In respect for the users of #selinux, we are going to use
#fedora-selinux on irc.freenode.net.  Please change the support
channel note in the relnotes to reflect this.

(Responding to comment #1):

All changes suggested have been made (with the exception of the
firewall screen comment, which was actually in the text already).  I
verified the path for audit2allow (which Russell confirmed -- if only
I had read ahead a bit). :-)  I spoke with Steve Dickson yesterday,
and apparently nfsv4 still can't run with SELinux enabled, so the best
we can do there is to pull the mention of the kernel bug (if it is, in
fact, fixed), and just note that usage of nfsv4 while running SELinux
is not supported at this time.

(Responding to Comment #2):

I'm on the fence regarding mentioning SIDs; I felt that it helped me
understand the mechanics a bit better, even if I was never going to
see a SID again.  If you feel strongly about it, I'll remove it, but
my inclination is to leave it in...

The point about file content and selinux=0 is a good one and should be
added... Ah, I see Karsten already has some suggested text (and right
where I was thinking of placing it, too) thanks -- added...

(Responding to comment #3):

Done.

Looks like we're done on this one...

Sorry that I'm late.  This is not critical, but if there's a chance to
fix it, please put it in.  In the question:

Q:. Can I test NFSv4?
A:. To do this, you must boot with selinux=0. There is a bug in this
alpha release of the kernel that prevents NFSv4 from running on an
SELinux-enabled system. To run NFSv4, you must disable SELinux.

this is a test release, not an alpha release.

Good point -- changed "alpha" to "test"...

Not sure if you are ready to drop the snapshot of the SELinux FAQ in
favor of a reference, but this bug has a specific item worth including
in the relnotes --  120126.  The topic is discussed in the FAQ,
farther down the page.  If we remove the FAQ, this item is probably
one to leave behind.

It deals with installing a system running SELinux with a preformatted
and populated /home.  None of the files in /home have the proper
context, either from previous policy or from never having lived with
policy.  Currently, if you select SELinux in enforcing mode during
install and you have an existing /home partition, the user will not be
able to login.  To resolve this, you must either relabel /home or
mount home with a --context that allows users to read and write to ~/home.

In Q. What are file contexts, the three options for fixfiles are
listed as 'check, restore, and label'.  They should be 'check,
restore, and relabel'.

Ed and I agree that the best thing to do for the reader from this
point forward is to remove the snapshot of the FAQ from the relnotes,
and replace it with an emphatic paragraph with a link to the FAQ.

The main reason for this is that the FAQ is flexible to take changes
right up until test release, where the relnotes are not.  We have
already had insurmountable challenges keeping them in sync, and are
convinced it is too difficult to continue to do so.

Here is a first pass at the replacement paragraph:

## begin

Fedora Core 2 test3 includes a fully working implementation of
SELinux.  SELinux is a major shift in the way users, programs, and
processes interact.  It is /highly/ recommended that you read the
Fedora SELinux FAQ before installing Fedora Core 2 test3:

http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/

Even if you are familiar with SELinux technology, refer to the FAQ for
the latest information from the Fedora Core SELinux developers.

## 30

And, yes, where it the /emphasis/ is, I really do mean <emphasis>. :-D

The bug catch from twaugh has been created as a standalone report
against the Fedora SELinux FAQ -- 120424

Re-opening so comment #11 won't be forgotten

Per comment #11, pulled the FAQ snapshot from the release notes, and
inserted a slightly-tweaked version of the replacement paragraph...