Setting up CVS repository and avoiding Selinux issues?
Daniel B. Thurman
dant at cdkkt.com
Wed Apr 29 15:09:36 UTC 2009
Todd Denniston wrote:
> Daniel B. Thurman wrote, On 04/28/2009 10:07 PM:
>> I am trying to get my CVS repository setup. Apparently,
>> it appears that the repository must be in the root directory,
>> otherwise I get selinux permission denials.
>>
>> What I tried to do initially was to locate the repository
>> on a NTFS filesystem for which the context is fusefs
>> which could not be changed, no matter what I tried.
>> I got selinux permission errors.
>>
> using a non Unix file system on a Unix system for your CVS repo will
> likely cause much hate and discontent while trying to manage permissions.
Why? Dan Walsh says it's possible. My goal was simply to be able
to serve CVS repositories if I decided to reboot under a different
OS (Win2K, XP, or Vista w/ cvsnt server) where my common
repository resides. That is why I use both ext3 & NTFS, serving
the "common denominator". It works for me for many applications,
just that I haven't solved the CVS issue.... yet.
>> Giving that up, I moved the repository to a ext3 filesystem
>> located on a separate drive/partition, mounted on /f-App1,
>> where the repository is located @ /f-App1/Develop/cvs, and did:
>>
>> cd /f-App1/Develop/
>> chown -R cvs:cvs cvs
>> chcon -R -t cvs_data_t cvs
>> find cvs -type d -exec chmod 755 {} \;
>> find cvs -type t -exec chmod 754 {} \;
>> ln -s /f-App1/Develop/cvs /cvs
> Are you looking to use :pserver: here? Have you considered ssh?
I am using :pserver:. Just have not yet figured out how to use ssh and
make this work for all of the above mentioned OSes, and so pserver
seems to work with all of the above OSes.
>> and I got selinux complaining that the files are not /cvs rooted.
> Can you give the ACTUAL error(s) from selinux & CVS?
I have the errors from selinux, but was not sure where
to find the errors from cvs, as I have no clue where the
logs are kept. I looked in /var/log directory and did not
find any cvs logs, so if you know, please let me know?
I have added Dan's blog to the end of this message, so that
you can read what he said. It is interesting to note in
DW's blog is that selinux context labels (at least in the
CVS case), may be an all or nothing proposition. What
if I also wish to have SVN right next to CVS, what are
my options? cvs_data_t OR svn_data_t? So does that
mean I cannot have both CVS and SVN in a common
directory? Ugh. I'll live. ;)
I wonder if it is possible to have multiple contexts for
a file such as "cvs_data_t | svn_data_t" which in this
case is an OR operation, uh, I am digressing, but still,
it seems perhaps we need more selinux flexibility?
Anyway, the following is a direct CVS login error, when
selinux context are not fully root "treed" with cvs_data_t
and according to DW:
# cvs login
Logging in to :pserver:dant at gold:2401/cvs
CVS password:
cvs [login aborted]: unrecognized auth response from gold: cvs pserver:
cannot open /cvs/CVSROOT/config: Permission denied
[1]
================================================================================
It seems, from what I read on DW's blog, that selinux is an
"all or nothing" proposition unless special steps are taken
to "root mount" the "middle tree of the tree repository"
directory as in the case to make the repository seen as "rooted" even
though it actually
resides "somewhere in the depths of the?
=================================================
Summary:
SELinux is preventing access to files with the default label, default_t.
Detailed Description:
SELinux permission checks on files labeled default_t are being denied. These
files/directories have the default label on them. This can indicate a
labeling
problem, especially if the files being referred to are not top level
directories. Any files/directories under standard system directories, /usr,
/var. /dev, /tmp, ..., should not be labeled with the default label. The
default
label is for files/directories which do not have a label on a parent
directory.
So if you create a new directory in / you might legitimately get this label.
Allowing Access:
If you want a confined domain to use these files you will probably need to
relabel the file/directory with chcon. In some cases it is just easier to
relabel the system, to relabel execute: "touch /.autorelabel; reboot"
Additional Information:
Source Context unconfined_u:system_r:cvs_t:s0-s0:c0.c1023
Target Context system_u:object_r:default_t:s0
Target Objects / [ dir ]
Source cvs
Source Path /usr/bin/cvs
Port <Unknown>
Host gold.cdkkt.com
Source RPM Packages cvs-1.11.22-14.fc9
Target RPM Packages filesystem-2.4.13-1.fc9
Policy RPM selinux-policy-3.3.1-131.fc9
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name default
Host Name gold.cdkkt.com
Platform Linux gold.cdkkt.com
2.6.27.21-78.2.41.fc9.i686 #1
SMP Mon Mar 23 23:45:58 EDT 2009 i686 i686
Alert Count 2
First Seen Wed 29 Apr 2009 07:20:37 AM PDT
Last Seen Wed 29 Apr 2009 07:20:37 AM PDT
Local ID fd681afa-1384-4d4d-a0b2-b4d73de6d9f0
Line Numbers
Raw Audit Messages
node=gold.cdkkt.com type=AVC msg=audit(1241014837.641:25681): avc:
denied { search } for pid=29785 comm="cvs" name="/" dev=sda7 ino=2
scontext=unconfined_u:system_r:cvs_t:s0-s0:c0.c1023
tcontext=system_u:object_r:default_t:s0 tclass=dir
node=gold.cdkkt.com type=SYSCALL msg=audit(1241014837.641:25681):
arch=40000003 syscall=5 success=no exit=-13 a0=97a9660 a1=8000 a2=1b6
a3=0 items=0 ppid=24676 pid=29785 auid=500 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=9 comm="cvs"
exe="/usr/bin/cvs" subj=unconfined_u:system_r:cvs_t:s0-s0:c0.c1023
key=(null)
[2]
================================================================================
This one is a doozy, or so it seems. Since I am cvs logging
in as a regular user, I suspect that your home environment
is being used, so cvs probably searches via your home directory
and perhaps also expects to find cvs context, which isn't there?
I think Dan Walsh may need to explain this one?
===================================================
Summary:
SELinux is preventing cvs (cvs) "search" to ./dant (user_home_dir_t).
Detailed Description:
SELinux denied cvs access to ./dant. If this is a CVS repository it has
to have
a file context label of cvs_data_t. If you did not intend to use ./dant
as a cvs
repository it could indicate either a bug or it could signal a intrusion
attempt.
Allowing Access:
You can alter the file context by executing chcon -R -t cvs_data_t
'./dant' You
must also change the default file context files on the system in order to
preserve them even on a full relabel. "semanage fcontext -a -t vcs_data_t
'./dant'"
Fix Command:
chcon -R -t cvs_data_t './dant'
Additional Information:
Source Context unconfined_u:system_r:cvs_t:s0-s0:c0.c1023
Target Context system_u:object_r:user_home_dir_t:s0
Target Objects ./dant [ dir ]
Source cvs
Source Path /usr/bin/cvs
Port <Unknown>
Host gold.cdkkt.com
Source RPM Packages cvs-1.11.22-14.fc9
Target RPM Packages
Policy RPM selinux-policy-3.3.1-131.fc9
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name cvs_data
Host Name gold.cdkkt.com
Platform Linux gold.cdkkt.com
2.6.27.21-78.2.41.fc9.i686 #1
SMP Mon Mar 23 23:45:58 EDT 2009 i686 i686
Alert Count 45
First Seen Tue 28 Apr 2009 07:10:56 PM PDT
Last Seen Tue 28 Apr 2009 07:38:16 PM PDT
Local ID ee15f482-ae66-4877-81e3-9a5fbc322aa6
Line Numbers
Raw Audit Messages
node=gold.cdkkt.com type=AVC msg=audit(1240972696.317:19091): avc:
denied { search } for pid=25395 comm="cvs" name="dant" dev=sda6
ino=141211 scontext=unconfined_u:system_r:cvs_t:s0-s0:c0.c1023
tcontext=system_u:object_r:user_home_dir_t:s0 tclass=dir
node=gold.cdkkt.com type=SYSCALL msg=audit(1240972696.317:19091):
arch=40000003 syscall=33 success=no exit=-13 a0=9b952c8 a1=0 a2=9b952c8
a3=80c5278 items=0 ppid=25393 pid=25395 auid=500 uid=500 gid=506
euid=500 suid=500 fsuid=500 egid=506 sgid=506 fsgid=506 tty=(none) ses=9
comm="cvs" exe="/usr/bin/cvs"
subj=unconfined_u:system_r:cvs_t:s0-s0:c0.c1023 key=(null)
>> So I did:
>>
>> cp -a /f-App1/Develop/cvs /cvs1
>> rm -f /cvs
>> ln -s /cvs1 /cvs
>>
>> And it worked.
>>
>> How can I place my repository in a non-rooted, non-standard
>> repository location and avoid the selinux complaints?
>>
>
> I am interested, because I maintain CVS repos on older systems that
> will probably migrate when RHEL 6 comes out, but Dan Walsh's blog site
> is not accessible.
Here is Dan Walsh's Blog:
====================================================================
/*Confining Service with SELinux*/
We have begun working on a guide to define how to confine different
services with SELinux. I have written on this before and am preparing
talks on /*Top three things to understand in fixing SELinux problems.
*/ <http://danwalsh.livejournal.com/22347.html>
I think giving real world examples is helpful.
Daniel Thurman posted the following to the fedora-list at redhat.com
[snip! Context of Daniel's Post]
SELinux is all about labeling. The problem Daniel is having here is the
cvs daemon is running as cvs_t. It is only allowed to read/write
certain directories/files based on their labels (cvs_data_t). He
executes the appropriate commands to set the DAC permissions and even
attempts to set the label to the correct type for SELinux, cvs_data_t.
The problem is he ignored the directories above. So cvs_t is not
allowed to search through the directories /F-app1/Develop directory to
find it's data. If he had executed chcon -R -t cvs_data_t /F-app1,
the entire directory tree would have the context cvs_data_t which the
cvs daemon (cvs_t) can read and traverse.
Directories created under / get a label of default_t, by default. All
files/directories created in these top level directories then inherit
the default_t label. Confined domains can not read default_t since we
do not know the value of the data created in these directories.
Therefore is is more secure to deny by default.
One other common mistake that Daniel is making here is the use of
chcon. chcon changes the labeling of the files/directories, but does
not tell the system about this alternate labeling. If a relabel gets
triggered on the system, for any reason, these labels could get changed
back to the default. You need to tell the system about the alternate
labeling using the "semanage fcontext" command.
# semanage fcontext -a -t cvs_data '/F-app1(/.*)?'
# restorecon -R -v /F-app1
Makes the changes permanent.
One last point, Daniel states that he tried to start put the CVS data
repository on an NTFS mount point, but SELinux does not allow the cvs
daemon (cvs_t) access to the fusefs (fusefs_t) file system. Daniel
tried to change the label on the NTFS file system, but he quickly found
out that NTFS does not support extended attributes and therefore does
not support SELinux labels.
1. He has two ways to make this work. He could have made a local
modification to SELinux policy using audit2allow, to allow the
cvs_t access to fusefs_t.
# grep fusefs /var/log/audit/audit.log | audit2allow -M mycvs
# semodule -i mycvs.pp
This will make a permanent change to SELinux policy that allows cvs_t
access to all fusefs file systems.
2. Another solution would be to just change the file context on this
ntfs file system mount point.
mount -o context=system_u:object_r:cvs_data_t:s0 NTFSDEVICE /F-app1
Which would tell the kernel that all files mounted at F-app1 will be
labeled cvs_data_t.
If the only fusefs file system on this server is for cvs, the first
solution is fine. Also if you want other confined domains to access the
NTFS file system, it might be better. On the other hand, if you have
multiple NTFS/Fusefs file systems it would probably be more secure to
only label the one NTFS file system as being accessible by CVS, using
the mount option.
====================================================================
More information about the fedora-list
mailing list