Re: Setting up CVS repository and avoiding Selinux issues?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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:[email protected]: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?


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>
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           
Platform Linux #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 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 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
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?


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

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

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>
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           
Platform Linux #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 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 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.
*/ <>
I think giving real world examples is helpful.

Daniel Thurman posted the following to the [email protected]
[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.

fedora-list mailing list
[email protected]
To unsubscribe:

[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux