danwalsh


Dan Walsh's Blog

Got SELinux?


Previous Entry Add to Memories Share Next Entry
Confining Service with SELinux
danwalsh
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 fedora-list@redhat.com


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.

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

and I got selinux complaining that the files are not /cvs rooted.

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?


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_t '/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.

  1. 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.

A question has come up on list about sharing the directory tree amoungst multiple confined domains.

danwalsh

2009-04-29 03:29 pm (UTC)

We could have labeled the directories above /F-app1/Develop as a context of usr_t or var_t. If you want to see all of the directories that cvs_t can search through you could execute the following command

sesearch --allow -s cvs_t -c dir -p search
Found 33 semantic av rules:
allow cvs_t sysctl_t : dir { getattr search } ;
allow cvs_t bin_t : dir { ioctl read getattr lock search open } ;
allow cvs_t cert_t : dir { ioctl read getattr lock search open } ;
allow cvs_t lib_t : dir { ioctl read getattr lock search open } ;
allow cvs_t tmp_t : dir { ioctl read write getattr lock add_name remove_name search open } ;
allow cvs_t usr_t : dir { getattr search } ;
allow cvs_t var_t : dir { getattr search } ;
allow cvs_t nscd_var_run_t : dir { getattr search } ;
allow cvs_t sssd_var_lib_t : dir { getattr search } ;
allow cvs_t winbind_var_run_t : dir { getattr search } ;
allow cvs_t cvs_tmp_t : dir { ioctl read write create getattr setattr lock unlink link rename add_name remove_name reparent search rmdir open } ;
allow cvs_t device_t : dir { ioctl read getattr lock search open } ;
allow cvs_t locale_t : dir { ioctl read getattr lock search open } ;
allow cvs_t cvs_t : dir { ioctl read getattr lock search open } ;
allow cvs_t etc_t : dir { ioctl read getattr lock search open } ;
allow cvs_t proc_t : dir { ioctl read getattr lock search open } ;
allow cvs_t var_lib_t : dir { ioctl read getattr lock search open } ;
allow cvs_t var_run_t : dir { ioctl read write getattr lock add_name remove_name search open } ;
allow cvs_t auth_cache_t : dir { getattr search } ;
allow cvs_t cvs_data_t : dir { ioctl read write create getattr setattr lock unlink link rename add_name remove_name reparent search rmdir open } ;
allow cvs_t proc_net_t : dir { ioctl read getattr lock search open } ;
allow cvs_t var_log_t : dir { getattr search } ;
allow cvs_t samba_var_t : dir { getattr search } ;
allow cvs_t avahi_var_run_t : dir { getattr search } ;
allow cvs_t cvs_var_run_t : dir { ioctl read write getattr lock add_name remove_name search open } ;
allow cvs_t sysctl_kernel_t : dir { ioctl read getattr lock search open } ;
allow cvs_t home_root_t : dir { getattr search } ;
allow cvs_t var_yp_t : dir { ioctl read getattr lock search open } ;
allow cvs_t var_t : dir { getattr search } ;
allow cvs_t etc_t : dir { getattr search } ;
allow cvs_t etc_t : dir { ioctl read getattr lock search open } ;
allow cvs_t var_run_t : dir { getattr search } ;
allow cvs_t net_conf_t : dir { getattr search } ;


So you could have setup the labeling above with

# semanage fcontext -a -t var_t '/F-app1(/.*)?'
# semanage fcontext -a -t var_t '/F-app1/Develop/cvs(/.*)?'
# restorecon -R -v /F-app1

And then you could have other confined domains access to other directories under Develop as long as those domains can search var_t. (Most can)


Confining Service with SELinux

dbthurman

2009-04-29 04:01 pm (UTC)

Hi Dan,

This is my first time using LiveJournal, so... bear with me ;)

I have read your blog and it is quite informative. What I ended
up doing is is to:

1) chcon -t cvs_data_t /f-App1
2) chcon -t cvs_data_t /f-App1/Develop
3) chcon -t cvs_data_t /f-App1/Develop/SC
4) chcon -t cvs_data_t /f-App1/Develop/SC/cvs

If one uses cvs command: cvs login, it works,
and no errors and selinux complaints. However...

If one uses an Eclipse or Netbeans IDE, logging
into cvs via their interfaces reports an error
that the User's home directory is not of proper
context: cvs_data_t. So adding in one more step:

5) chcon -t cvs_data_t $HOME/dant

Solves the problem.

Please note that once the Repository "tree" is resolved,
adding a 6th step:

6) ln -s /f-App1/Develop/SC/cvs /cvs

And changing the cvs configuration such that
the pathname is chamged to: /cvs (instead of
using the actual pathname of the repository)
and restarting xinet and resetting the CVSROOT
variable, now all works fine. No CVS nor Selinux
errors, so far.

How about selinux context, what I was proposing
was to add the capability to have multiple context.
For example, starting with /f-App1 directory, if
I wanted to allow cvs and svn access, I would add
this context as follows:

chcon -default -t default_t /f-App1
chcon -add -t cvs_data_t /f-App1
chcon -add -t svn_data_t /f-App1

So, you should be able to add/append/delete/remove/...
commands to manipulate selinux context, unless there
is something about how context on the physical drive
that does not make this possible?

PS: I will add this message to the Fedora User's
group for those who claim they cannot access your
blog.

Re: Confining Service with SELinux

danwalsh

2009-04-29 04:32 pm (UTC)

Adding multiple context to a single directory has been discussed in the past, but it has been denied, since it becomes very difficult to analyze the policy. So a better case is to create a new type or a type that both confined domains can search/read and then set the context to one of those.

I have never heard of ~/HOME/dant, Why does the cvs daemon need to look in the users homedir?

Re: Confining Service with SELinux

dbthurman

2009-04-29 04:50 pm (UTC)

Ok, about the proposal. How can one do what you suggest,
to add a "new type or type" to allow both cvs/svn context
for which these directories are next to each other in the
same common parent?

As for CVS searching the user's home directory, this was
apparently done via the Eclipse/Netbeans IDE, where cvs/svn
is supported. When CVS repository is opened, that user's
home directory is searched as the selinux complaint, specific
to Eclipse, is shown below:
======================================

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
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 4
First Seen Wed 29 Apr 2009 08:31:36 AM PDT
Last Seen Wed 29 Apr 2009 08:31:36 AM PDT
Local ID ced0971f-d22f-49c9-837f-60ae3a30ead2
Line Numbers

Raw Audit Messages

node=gold.cdkkt.com type=AVC msg=audit(1241019096.514:26331): avc: denied { search } for pid=7999 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(1241019096.514:26331): arch=40000003 syscall=33 success=no exit=-13 a0=821b808 a1=0 a2=821b808 a3=80bd684 items=0 ppid=7997 pid=7999 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)

Re: Confining Service with SELinux

dbthurman

2009-04-29 05:16 pm (UTC)

Note:
===========================================
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'"
===========================================
"semanage fcontext -a -t vcs_data_t './dant'" <<< is clearly wrong. Mispelled vcs : S/B cvs ;)

I set the context of $HOME/dant to cvs_data_t and this is NOT the
thing to do because too many other applications (dovecot is one)
expects user_home_t. So it looks like I will need a different
type to handle all cases of Repositories (cvs, svn, git, whatever)?

Thanks!
Dan

Re: Confining Service with SELinux

danwalsh

2009-04-29 05:59 pm (UTC)

$HOME/dant should be labeled user_home_t not user_home_dir_t. Not sure who created it with the wrong context.

I would not run the semanage command on it, You should be able to just run restorecon on it to set it to the default label.


Re: Confining Service with SELinux

dbthurman

2009-04-29 06:48 pm (UTC)

OK, I see what you mean!

I fixed my home directory to replace all context
of user_home_dir_t to user_home_t and this fixed
the permissions problems regarding HOME. All that
is left now is the /tmp access required by NetBeans.


Re: Confining Service with SELinux

dbthurman

2009-04-29 06:06 pm (UTC)

My home directory context is: user_home_t.

I don't know where I specified user_home_dir_t
as I never used that. I was testing and switched
between cvs_data_t and user_home_t.

Re: Confining Service with SELinux

dbthurman

2009-04-29 06:02 pm (UTC)

Additional Information:

For Netbeans, the problem is greatly exaberated if the context of
the user's home directory is not of context cvs_data_t. Setting
the user's home directory to cvs_data_t gets past the permissions
error (cvs checkout: cannot open /home/dant/.cvsignore: Permission
denied), but then again, it also wants:

cannot create_adm_p /tmp/cvs-serv25975/NetBeans
Permission denied

So, for Netbeans, it is much more picker than Eclipse,
or so it seems.

Re: Confining Service with SELinux

danwalsh

2009-04-29 06:36 pm (UTC)

We do not want to label stuff in the home directory as cvs_data_t, I would rather write custom policy to allow cvs_t access to the home dir. What AVC's are you seeing generated about Netbeans?

Re: Confining Service with SELinux

dbthurman

2009-04-29 06:54 pm (UTC)

As I posted in an above thread, the context
issue was centered around the fact that I had
multiple user_home_dir_t in various places in
my $HOME directory. With that removed, CVS was
happy that it works completely for Eclipse.

Netbeans wants access to:
cannot create_adm_p /tmp/cvs-serv25975/NetBeans

I think this is the last part of the puzzle to solve.

Once resolved, I have to figure how how to make
all the changes permanent.

As for where the user_home_dir_t comes from, that
is beyond me. I will later try to reboot with /.autorename
and see what happens.

Re: Confining Service with SELinux

danwalsh

2009-04-29 07:06 pm (UTC)

Just email me at dwalsh@redhat.com the /var/log/audit/audit.log so I can look at the netbeans issue.

Re: Confining Service with SELinux

dbthurman

2009-04-30 02:54 pm (UTC)

I have carefully reviewed the following link, especially that concerning
the passwd, readers, writers file, I believe having these files correctly
setup removes the two "permissions" problems and has nothing to do with
selinux, but instead, with CVS configuration. Interestingly, selinux
reports access errors because somehow the cvs system is expecting a
valid user (as anonymous or local user) from the CVSROOT passwd file
and by further extension the readers/writers files for read/write access
rights.

http://dvbblog.wordpress.com/2009/02/06/how-to-setup-cvs-server-on-fedora-9/

What is incomplete in the above link is information in using selinux
to properly set cvs_data_t context, properly mounting non-rooted cvs
existing repositories.

From what I see, the key to setting up CVS is:

1) CVS repository must be rooted.
2) Use mount --bind /non-rooted/repository /cvs
3) Create CVS user/group assignments and set /cvs file/directory ownerships
4) Use semanage fcontext to permanently set /cvs to cvs_data_t context
5) Using the CVS/CVSROOT repository, add two files: readers, writers, then
checkout passwd and configure these files carefully. Failure to follow
configuration properly may result in cryptic error reporting.
6) Properly configure /etc/xinetd.d/cvs, and restart xinetd
7) If you want remote access to the CVS repository, be sure to add
port 2401 tcp/udp to the firewall tables.

I have tested the CVS server, command line login/logout/..., Eclipse,
and Netbeans and found these to be working just fine now.


Hope I did not miss anything else!


Thanks for your help!
Dan

Thanks for your good explanation, but it did not work for me

cgroove

2012-08-01 09:31 pm (UTC)

Salut Dan,

thanks for your nice documentation. I followed it, but
failed, i must misunderstood something.

My system is a centos 6.3. It is running on a server with
a RAID subsystem, that stores all user homes and data.
The directory /home/cvsuser is a link to the raid-partition:

/home/cvsroot -> /media/dataDrv/Data/cvsroot

where /media/dataDrv/Data/cvsroot is located on that
raid-drive and

/media/dataDrv/Data/cvsroot/repository

holds my repository.

Due to the individual repo-directories i did:

$ chcon -R -t cvs_data_t /media/dataDrv/Data/cvsroot
$ semanage fcontext -a -t cvs_data_t '/media/dataDrv/Data/cvsroot(/.*)?'
$ restorecon -R -v /media/dataDrv/Data/cvsroot

With a setenforce 0 the remote cvs access works,
but when i enable selinux, i get the following
error:

cvs [status aborted]: unrecognized auth response from barso: cvs pserver: cannot open /home/cvsroot/repository/CVSROOT/config: Permission denied

That sounds strange for me, because a give me no
hint:

$ ls -l --lcontext /home/cvsroot/repository/CVSROOT/config
-rw-rw-r--. 1 system_u:object_r:cvs_data_t:s0 cvsroot cvsuser 986 7. Nov 2004 /home/cvsroot/repository/CVSROOT/config

Any ideas ????

Christian


Re: Thanks for your good explanation, but it did not work for me

danwalsh

2012-08-02 12:35 pm (UTC)

Most likely your avc's related to not being able to search through the /media/dataDrv/Data directories.

What does ausearch -m avc -ts recent show, after trying to access the cvs in enforcing mode?

Re: Thanks for your good explanation, but it did not work for me

cgroove

2012-08-02 07:52 pm (UTC)

Salut Dan,

it says:

# ausearch -m avc -ts recent

----
time->Thu Aug 2 21:40:51 2012
type=SYSCALL msg=audit(1343936451.004:76): arch=c000003e syscall=2 success=no exit=-13 a0=26f8880 a1=0 a2=1b6 a3=0 items=0 ppid=2458 pid=3771 auid=4294967295 uid=600 gid=600 euid=600 suid=600 fsuid=600 egid=600 sgid=600 fsgid=600 tty=(none) ses=4294967295 comm="cvs" exe="/usr/bin/cvs" subj=system_u:system_r:cvs_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1343936451.004:76): avc: denied { search } for pid=3771 comm="cvs" name="Data" dev=sda1 ino=97910785 scontext=system_u:system_r:cvs_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir
----

time->Thu Aug 2 21:40:51 2012
type=SYSCALL msg=audit(1343936451.121:77): arch=c000003e syscall=2 success=no exit=-13 a0=26f8900 a1=0 a2=1b6 a3=0 items=0 ppid=2458 pid=3771 auid=4294967295 uid=600 gid=600 euid=600 suid=600 fsuid=600 egid=600 sgid=600 fsgid=600 tty=(none) ses=4294967295 comm="cvs" exe="/usr/bin/cvs" subj=system_u:system_r:cvs_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1343936451.121:77): avc: denied { search } for pid=3771 comm="cvs" name="Data" dev=sda1 ino=97910785 scontext=system_u:system_r:cvs_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir

Re: Thanks for your good explanation, but it did not work for me

danwalsh

2012-08-02 08:13 pm (UTC)

file_t means there is no labeles at a higher level. I would just do lable everything under /media as usr_t, and then the cvs data as cvs_data_t.



Re: Thanks for your good explanation, but it did not work for me

danwalsh

2012-08-02 08:15 pm (UTC)

# semanage fcontext -a -t usr_t '/media/dataDrv(/.*)?'
# semanage fcontext -a -t cvs_data_t '/media/dataDrv/Data/cvsroot(/.*)?'
# restorecon -R -v /media/dataDrv

Or just do.

# semanage fcontext -a -t cvs_data_t '/media/dataDrv(/.*)?'
# restorecon -R -v /media/dataDrv

Re: Thanks for your good explanation, but it did not work for me

cgroove

2012-08-07 05:42 am (UTC)

Salut Dan,

it looks like, that a problem was solved. When i do
a cvs diff on the client, i get:

$ cvs diff
[Error: Irreparable invalid markup ('<file...>') in entry. Owner must fix manually. Raw contents below.]

Salut Dan,

it looks like, that a problem was solved. When i do
a cvs diff on the client, i get:

$ cvs diff <file...>

cvs [diff aborted]: cannot stat directory /var/lock/cvs/lxOffice4groovesys: Permission denied

Ok, it seems to be the same problem as you described.

on the server i entered:

$ ausearch -m avc -ts recent

and i received:

time->Tue Aug 7 07:26:38 2012
type=SYSCALL msg=audit(1344317198.100:170): arch=c000003e syscall=4 success=no exit=-13 a0=e91700 a1=7ffffc6f14f0 a2=7ffffc6f14f0 a3=7 items=0 ppid=4013 pid=4014 auid=4294967295 uid=600 gid=600 euid=600 suid=600 fsuid=600 egid=600 sgid=600 fsgid=600 tty=(none) ses=4294967295 comm="cvs" exe="/usr/bin/cvs" subj=system_u:system_r:cvs_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1344317198.100:170): avc: denied { search } for pid=4014 comm="cvs" name="lock" dev=sdc2 ino=7864969 scontext=system_u:system_r:cvs_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lock_t:s0 tclass=dir
----
time->Tue Aug 7 07:26:38 2012
type=SYSCALL msg=audit(1344317198.100:171): arch=c000003e syscall=4 success=no exit=-13 a0=e91740 a1=7ffffc6f12a0 a2=7ffffc6f12a0 a3=7 items=0 ppid=4013 pid=4014 auid=4294967295 uid=600 gid=600 euid=600 suid=600 fsuid=600 egid=600 sgid=600 fsgid=600 tty=(none) ses=4294967295 comm="cvs" exe="/usr/bin/cvs" subj=system_u:system_r:cvs_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1344317198.100:171): avc: denied { search } for pid=4014 comm="cvs" name="lock" dev=sdc2 ino=7864969 scontext=system_u:system_r:cvs_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lock_t:s0 tclass=dir
----
time->Tue Aug 7 07:32:34 2012
type=SYSCALL msg=audit(1344317554.292:185): arch=c000003e syscall=4 success=no exit=-13 a0=dcb700 a1=7fffa85d36e0 a2=7fffa85d36e0 a3=7 items=0 ppid=4069 pid=4070 auid=4294967295 uid=600 gid=600 euid=600 suid=600 fsuid=600 egid=600 sgid=600 fsgid=600 tty=(none) ses=4294967295 comm="cvs" exe="/usr/bin/cvs" subj=system_u:system_r:cvs_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1344317554.292:185): avc: denied { search } for pid=4070 comm="cvs" name="lock" dev=sdc2 ino=7864969 scontext=system_u:system_r:cvs_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lock_t:s0 tclass=dir
----
time->Tue Aug 7 07:32:34 2012
type=SYSCALL msg=audit(1344317554.292:186): arch=c000003e syscall=4 success=no exit=-13 a0=dcb740 a1=7fffa85d3490 a2=7fffa85d3490 a3=7 items=0 ppid=4069 pid=4070 auid=4294967295 uid=600 gid=600 euid=600 suid=600 fsuid=600 egid=600 sgid=600 fsgid=600 tty=(none) ses=4294967295 comm="cvs" exe="/usr/bin/cvs" subj=system_u:system_r:cvs_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1344317554.292:186): avc: denied { search } for pid=4070 comm="cvs" name="lock" dev=sdc2 ino=7864969 scontext=system_u:system_r:cvs_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lock_t:s0 tclass=dir

I'll cvs is running through /var/lock/cvs but i think
its not a good idea to label the entire path.
Besides selinux shall accept, that the label for
/var/lock should be fine for a lock access !

Alternativly, do you think that it's a good idea
to move the cvs.locks into the cvsusers home, where
the labeling of the full path is ok?

Thank you for your held
christian

Re: Thanks for your good explanation, but it did not work for me

cgroove

2012-08-08 04:41 am (UTC)

Salut Dan,

for any reason, my recent posting seemed to be
saved somewhere else. I'll guess some output of
my shell messed up the blog parser.

Ok, i went into another problem, cause an

[user@client] cvs diff genSymlinks.sh

gave me an:
cvs [diff aborted]: cannot stat directory /var/lock/cvs/...

I found out, that the labels for the path /var/lock
did not match the selinux settings.
Thanks to your help, i got my home of cvsroot,
running under /media/dataDrv/Data/cvsroot.

cvs was able to access (under selinux) this
directory, so i created a /home/cvsroot/repLocks
directory and performed:

[root@server] semanage fcontext -a -t cvs_data_t '/media/dataDrv/Data/cvsroot/repLocks(/.*)?'

[root@server] restorecon -R -v /media/dataDrv

[root@server] vi /media/dataDrv/Data/cvsroot/repository/CVSROOT/config
and entered the lock-dir param as follows:
LockDir=/home/cvsroot/repLocks

[root@server] service xinetd restart

and it worked!! Yepeeehh!!!

Thank you Dan!



Edited at 2012-08-08 04:43 am (UTC)

Re: Thanks for your good explanation, but it did not work for me

cgroove

2012-08-02 08:04 pm (UTC)

Dan,

that looks strange to me:

# ls -l --lcontext /home/cvsroot
lrwxrwxrwx. 1 unconfined_u:object_r:cvs_data_t:s0 root root 27 13. Jul 07:57 /home/cvsroot -> /media/dataDrv/Data/cvsroot

seems to be ok, but:

# ls -l --lcontext /media/dataDrv/Data
drwsrws---. 12 system_u:object_r:cvs_data_t:s0 cvsroot cvsuser 4096 14. Jul 2010 cvsroot
(and others ...)

and now for some completly different:

ls -ld --lcontext /media/dataDrv/Data
drwxr-xr-x. 5 system_u:object_r:file_t:s0 root root 4096 25. Jun 2010 /media/dataDrv/Data

That's ok for me, the parent of cvsroot is
not labeled with cvs_data_t ... but for
who the back is cvs seeking its parent dir ??

The recent ausearch output tells me, that
cvs is access its parent and the hooked
selinux expexted it it labeled as cvs_data_t.

Did i misunderstood something ???

Thanks you Dan!
Christian



Re: Thanks for your good explanation, but it did not work for me

danwalsh

2012-08-03 11:01 am (UTC)

Well the symbolic link does not remove the requirement that the cvs daemon still needs to search through the /media /media/dataDrv and /media/dataDrv/Data directory to get the the cvs root directory. If it is not allowed to search any one of those directories the cvs daemon will not work. It is the same for ordinary Ownership/Permissions. Following a symbolic link does not remove or bypass these requirements.

You are viewing danwalsh