On 04/28/2009 10:07 PM, Daniel B. Thurman wrote: I blogged on your email http://danwalsh.livejournal.com/28027.html

Todd Denniston wrote: 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. 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. 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@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) 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(a)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. ====================================================================

On 04/29/2009 11:20 AM, Daniel B. Thurman wrote: Well I would argue they are very flexible. I did give you a couple of solutions but there are theoretically multiple others. And I am always willing to accept other solutions. svn and git seem to be using http_sys_content_t for their context so I guess we could attempt to allow those domains access to cvs_data? I guess maybe we should have had this conversation on the blog. There are many context that most confined services can traverse. For example usr_t, etc_t, var_t I have added a comment to my blog. Yes. This list is still available. Last message is 4/28 fron me. :^)