SELinux is preventing named from write access

It seems like the SELinux profile in CentOS5 may not be correct by default. In my /var/log/messages file, I have thousands of entries per month consisting of:

Jul 4 05:01:04 fw1-hosho setroubleshoot: SELinux is preventing /usr/sbin/named (named_t) "write" access to named (named_conf_t). For complete SELinux messages. run sealert -l 663ea169-d194-4c49-a5bb-a6a4bb707990

Here's the output of the sealert command:

# sealert -l 663ea169-d194-4c49-a5bb-a6a4bb707990
Summary
    SELinux is preventing /usr/sbin/named (named_t) "write" access to named
    (named_conf_t).

Detailed Description
    SELinux denied access requested by /usr/sbin/named. It is not expected that
    this access is required by /usr/sbin/named and this access may signal an
    intrusion attempt. It is also possible that the specific version or
    configuration of the application is causing it to require additional access.
    Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this
    package.

Allowing Access
    Sometimes labeling problems can cause SELinux denials.  You could try to
    restore the default system file context for named, restorecon -v named.
    There is currently no automatic way to allow this access. Instead, you can
    generate a local policy module to allow this access - see
    http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 - or you can
    disable SELinux protection entirely for the application. Disabling SELinux
    protection is not recommended. Please file a
    http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package.
    Changing the "named_disable_trans" boolean to true will disable SELinux
    protection this application: "setsebool -P named_disable_trans=1."

    The following command will allow this access:
    setsebool -P named_disable_trans=1

Additional Information        

Source Context                system_u:system_r:named_t
Target Context                root:object_r:named_conf_t
Target Objects                named [ dir ]
Affected RPM Packages         bind-9.3.3-8.el5 [application]
Policy RPM                    selinux-policy-2.4.6-30.el5
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   plugins.disable_trans
Host Name                     fw1-shimo.hq.example.org.
Platform                      Linux fw1-shimo.hq.example.org.
                              2.6.18-8.1.6.el5 #1 SMP Thu Jun 14 17:29:04 EDT
                              2007 x86_64 x86_64
Alert Count                   70481
Line Numbers                  

Raw Audit Messages            

avc: denied { write } for comm="named" dev=md1 egid=25 euid=25
exe="/usr/sbin/named" exit=-13 fsgid=25 fsuid=25 gid=25 items=0 name="named"
pid=2628 scontext=system_u:system_r:named_t:s0 sgid=25
subj=system_u:system_r:named_t:s0 suid=25 tclass=dir
tcontext=root:object_r:named_conf_t:s0 tty=(none) uid=25

The most helpful web page that I've found so far is the thread "Permissions Issue starting Bind 9.3.1". The gist seems to be that RedHat (and CentOS) are using a chroot bind installation in conjunction with an SELinux policy that expects the bind configuration files to be in a non-chroot setup. But there aren't very clear instructions there on fixing it.

Setting up svn+ssh on an alternate point for TortoiseSVN

This builds off a post to the TortoiseSVN user list: Specifying custom port for svn+ssh: a workaround

1. Right-click on the Pageant icon in the system tray (I'm assuming that you're loading the SSH public key that you use for SVN into Pageant).
   
2. Choose "New Session"
   
3. Enter the hostname / IP address and SSH port that you'll be connecting to. If you're going to connect as "svn+ssh://thomas@svn.tgharold.com:2222", then this would be "svn.tgharold.com" and "2222".
   
4. Go back to the "Session" tab and name the session as "svn.tgharold.com:2222".
   

Now you will be able to use both TortoiseSVN and the command-line version of SVN to talk to your repository over the alternate SSH port.

Why do this?

This is useful for cases where you want to put a SVN server on a publicly accessible IP address. What you will find is that if you leave SSH running on the default port, you will be inviting attacks on your SSH server. On the other hand, if you put the SSH server on an alternate port, you'll find that it gets attacked a lot less often (1-2 orders of magnitude difference would be likely).

Since mid-Oct of last year (around 8.5 months), we've logged 90,300 attack attempts against our SSH server. Usually they come in batches of attempting to guess accounts that normally exist or by attacking a list of common usernames. Since we don't allow root login, we don't allow password authentication, we only allow public key authentication and our SSH keys are limited to running "svnserve -t", we have yet to see a break-in attempt succeed.

LVM and SELinux

I was a bit perplexed... I had created a LV called /dev/vg/svn, had it mounted, was reading/writing data to it with no issues. But after I rebooted the CentOS5 server, I'm unable to mount the LV.

[root@localhost /]# /usr/sbin/pvscan
PV /dev/md6   VG vg   lvm2 [144.78 GB / 59.78 GB free]
Total: 1 [144.78 GB] / in use: 1 [144.78 GB] / in no VG: 0 [0   ]
[root@localhost /]# /usr/sbin/vgscan
Reading all physical volumes.  This may take a while...
Found volume group "vg" using metadata type lvm2
[root@localhost /]# /usr/sbin/lvscan
No volume groups found
[root@localhost /]# /usr/sbin/lvdisplay
No volume groups found
[root@localhost /]# /usr/sbin/lvdisplay vg
--- Logical volume ---
LV Name                /dev/vg/svn
VG Name                vg
LV UUID                taYjia-BWWs-IWG3-313k-VoC2-ghik-01mFCg
LV Write Access        read/write
LV Status              NOT available
LV Size                85.00 GB
Current LE             21760
Segments               1
Allocation             inherit
Read ahead sectors     0

[root@localhost /]# 

So lvdisplay knows that the LV is there, but only if I tell it to look at the VG named "vg".

...

Turns out that it's an SELinux issue. Because SELinux was blocking access to the /etc/lvm/.cache file, it was causing problems. Fixing it was as simple as:

# cd /etc/lvm
# /sbin/restorecon -v .cache
# /usr/sbin/lvscan
inactive          '/dev/vg/svn' [85.00 GB] inherit

CentOS5: Moving /var/log to a separate volume

One thing I like to do is put /var/log on its own volume. That keeps the root volume from overflowing and also gets the log files out of the way. However, in CentOS5 (and probably RHEL5), SELinux is probably going to complain unless we tell it to "fixup" the new filesystem.

1. Create the filesystem (I use ext3, so # /sbin/mke2fs -j /dev/mdX)
   
2. Mount it at a temporary location: # mkdir /mnt/log ; mount /dev/mdX /mnt/log
   
3. Copy the contents: # cp -a /var/log/* /mnt/log/
   
4. It may be necessary to "fixup" the new volume: # cd /mnt/log ; /sbin/restorecon -R *
   
5. Edit the /etc/fstab file to mount the new volume at /var/log
   
6. Reboot
   

AFAIK, that's the extent of what's needed. Looking at the directory listings using "ls -lZ" seems to show the correct SELinux flags on the files between the two different directories.