Re: [PATCH] Set SELinux context of host ssh keys correctly after reinstallation
by Dominick Grift
https://fedorahosted.org/pipermail/cobbler-devel/2011-March/001950.html
I have been told that snippet discussed above is executed by anaconda.
Allow anaconda to run setfiles (restorecon) in the setfiles_t domain
so that it is allowed to restore contexts of all files even if the
unconfined module is disabled.
Signed-off-by: Dominick Grift <domg472(a)gmail.com>
---
:100644 100644 dd1522d... e2df760... M policy/modules/admin/anaconda.te
policy/modules/admin/anaconda.te | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/policy/modules/admin/anaconda.te b/policy/modules/admin/anaconda.te
index dd1522d..e2df760 100644
--- a/policy/modules/admin/anaconda.te
+++ b/policy/modules/admin/anaconda.te
@@ -27,6 +27,7 @@ libs_domtrans_ldconfig(anaconda_t)
logging_send_syslog_msg(anaconda_t)
seutil_domtrans_semanage(anaconda_t)
+seutil_domtrans_setfiles(anaconda_t)
seutil_domtrans_setsebool(anaconda_t)
userdom_user_home_dir_filetrans_user_home_content(anaconda_t, { dir file lnk_file fifo_file sock_file })
--
1.7.4
13 years, 1 month
update breaks sandbox (2.0.83-33.3.fc13.x86_64)
by Christoph A.
Hi,
since today's update all of my sandboxes are broken.
By "broken" I mean that the sandbox window opens but remains black and
doesn't start the application.
I run various sandboxes some with permanent homedir some without - all
seam to be affected.
One of them is for example this very usual one:
sandbox -X -t sandbox_web_t firefox
The following packages where updated today:
Updated: libvirt-client-0.8.2-2.fc13.x86_64
Updated: policycoreutils-2.0.83-33.3.fc13.x86_64
Updated: policycoreutils-python-2.0.83-33.3.fc13.x86_64
Updated: policycoreutils-sandbox-2.0.83-33.3.fc13.x86_64
Updated: libvirt-python-0.8.2-2.fc13.x86_64
Updated: policycoreutils-gui-2.0.83-33.3.fc13.x86_64
Updated: tzdata-2011b-3.fc13.noarch
Updated: tzdata-java-2011b-3.fc13.noarch
Can somebody confirm this?
kind regards,
Christoph A.
13 years, 1 month
Re: nginx policy
by Dominick Grift
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/14/2011 11:14 AM, Mossburg wrote:
> On Mon, Mar 14, 2011 at 10:26 AM, Dominick Grift <domg472(a)gmail.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 03/14/2011 10:07 AM, Mossburg wrote:
>>> I'm currently trying to write a policy for the nginx webserver.
>>
>> It is probably better to make this webserver run in the httpd_t domain.
>
> It was my first idea but i didn't if it was a good idea to use an
> existing policy, written for a specific process.
>
>> That means that you would have to add file context specifications for
>> some files included with the nginx package:
>>
>> its executable file, configuration file, pid file, log, lib and init
>> script file.
>
> To make it permanent i would have to write a policy only with a .fc file ?
>
>> You did not include your nginx.fc file and so i cannot suggest these
>> changes.
>
> # nginx executable will have:
> # label: system_u:object_r:nginx_exec_t
> # MLS sensitivity: s0
> # MCS categories: <none>
>
> /usr/sbin/nginx -- gen_context(system_u:object_r:nginx_exec_t,s0)
to test (temporary label)
chcon -t httpd_exec_t /usr/sbin/nginx
to make it permanent locally
semanage fcontext -a -t httpd_exec_t /usr/sbin/nginx
> /var/run/nginx.pid gen_context(system_u:object_r:nginx_var_run_t,s0)
semanage fcontext -a -t httpd_var_run_t /var/run/nginx.pid
> /var/log/nginx(/.*)? gen_context(system_u:object_r:nginx_var_log_t,s0)
to test (temporary label)
chcon -R -t httpd_log_t /var/log/nginx
to make permanent locally
semanage fcontext -a -t httpd_log_t "/var/log/nginx(/.*)?"
> /var/lib/nginx(/.*)? gen_context(system_u:object_r:nginx_var_lib_t,s0)
chcon -R -t httpd_var_lib_t /var/lib/nginx
semanage fcontext -a -t httpd_var_lib_t "/var/lib/nginx(/.*)?"
> /etc/nginx(/.*)? gen_context(system_u:object_r:nginx_conf_t,s0)
chcon -R -t httpd_config_t /etc/nginx
semanage fcontext -a -t httpd_config_t "/etc/nginx(/.*)?"
use existing apache locations/types:
default system webroot:
/var/www
you can also just add the above fc specs to a .fc file (you may need to
require the types used in the fc file in your te file)
Instead i would just use chcon or semanage fcontext plus restorecon.
Once you confirmed that it works, you can suggest your changes upstream
so that Fedora /refpolicy can make the changes to the apache module.
Then it should work by default for you on a future update of selinux-policy.
>
>
>> Of course you can also do it your way and write policy from scratch but
>> doing this for a web server is probably not the best idea. webservers
>> can be pretty complex and can be configured in many ways.
>>
>> So again, i would suggest trying to run nginx in the existing httpd_t
>> domain instead so that httpd's proven policy applies to nginx, Saves
>> work/time.
>
> I totally agree.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk197boACgkQMlxVo39jgT//VwCeIUEoJtN1SXUKm4EFTeXw4wQG
6HEAn0nWI3J3YWvhW93PqiRi6NZDH2jk
=ycnB
-----END PGP SIGNATURE-----
13 years, 1 month
nginx policy
by Mossburg
I'm currently trying to write a policy for the nginx webserver.
As i am a beginner i would like to know if somebody could give me
some advices to avoid common mistakes.
To write this policy i've followed this steps :
- generate a policy with policygentool
- analyse logs to adapt the policy
- apply some more changes to fit my needs
- run the nginx webserver with the new policy loaded.
For instant, i am running a simple website that serves only static
content, i have no "avc denied" in logs.
How could i fully test the policy in order to validate it ? How could
i improve the policy ?
Here is my type enforcement file :
#### nginx.te ####
policy_module(nginx,1.0.0)
require {
type sysctl_t;
type sysctl_kernel_t;
type node_t;
}
########################################
#
# Declarations
#
type nginx_t;
type nginx_exec_t;
domain_type(nginx_t)
init_daemon_domain(nginx_t, nginx_exec_t)
# configuration files
# TODO: use files_config_file instead files_type
type nginx_conf_t;
files_type(nginx_conf_t)
# pid files
type nginx_var_run_t;
files_pid_file(nginx_var_run_t)
# log files
type nginx_var_log_t;
logging_log_file(nginx_var_log_t)
# var/lib files
type nginx_var_lib_t;
files_type(nginx_var_lib_t)
########################################
#
# nginx local policy
#
# Check in /etc/selinux/refpolicy/include for macros to use instead of
allow rules
# Some common macros (you might be able to remove some)
files_search_etc(nginx_t)
libs_use_ld_so(nginx_t)
libs_use_shared_libs(nginx_t)
miscfiles_read_localization(nginx_t)
## internal communication is often done using fifo and unix sockets.
allow nginx_t self:fifo_file { read write };
allow nginx_t self:unix_stream_socket create_stream_socket_perms;
# conf files
allow nginx_t nginx_conf_t:dir list_dir_perms;
allow nginx_t nginx_conf_t:file read_file_perms;
allow nginx_t nginx_conf_t:lnk_file read_lnk_file_perms;
files_etc_filetrans(nginx_t,nginx_conf_t, { file dir })
# pid file
allow nginx_t nginx_var_run_t:file manage_file_perms;
allow nginx_t nginx_var_run_t:sock_file manage_file_perms;
allow nginx_t nginx_var_run_t:dir rw_dir_perms;
files_pid_filetrans(nginx_t,nginx_var_run_t, { file sock_file })
# log files
allow nginx_t nginx_var_log_t:file { create_file_perms append };
allow nginx_t nginx_var_log_t:sock_file create_file_perms;
allow nginx_t nginx_var_log_t:dir { rw_dir_perms setattr };
logging_log_filetrans(nginx_t,nginx_var_log_t,{ sock_file file dir })
# var/lib files for nginx
allow nginx_t nginx_var_lib_t:file create_file_perms;
allow nginx_t nginx_var_lib_t:sock_file create_file_perms;
allow nginx_t nginx_var_lib_t:dir { search_dir_perms create_dir_perms };
files_var_lib_filetrans(nginx_t,nginx_var_lib_t, { file dir sock_file })
## Networking basics (adjust to your needs!)
sysnet_dns_name_resolve(nginx_t)
corenet_tcp_sendrecv_all_if(nginx_t)
corenet_tcp_sendrecv_all_nodes(nginx_t)
corenet_tcp_sendrecv_all_ports(nginx_t)
#corenet_non_ipsec_sendrecv(nginx_t)
corenet_all_recvfrom_unlabeled(nginx_t)
corenet_tcp_connect_http_port(nginx_t)
#corenet_tcp_connect_all_ports(nginx_t)
## if it is a network daemon, consider these:
#corenet_tcp_bind_all_ports(nginx_t)
#corenet_tcp_bind_all_nodes(nginx_t)
corenet_tcp_bind_http_port(nginx_t)
corenet_tcp_bind_http_cache_port(nginx_t)
allow nginx_t self:tcp_socket { listen accept };
allow nginx_t node_t:tcp_socket node_bind;
# Init script handling
init_use_fds(nginx_t)
init_use_script_ptys(nginx_t)
domain_use_interactive_fds(nginx_t)
# System
allow nginx_t self:capability { setuid net_bind_service setgid dac_override };
kernel_read_kernel_sysctls(nginx_t)
#allow nginx_t sysctl_kernel_t:dir search;
#allow nginx_t sysctl_kernel_t:file read;
#allow nginx_t sysctl_t:dir search;
allow nginx_t etc_t:dir search;
# Access apache content
apache_manage_sys_content(nginx_t)
apache_search_sys_content(nginx_t)
apache_read_sys_content(nginx_t)
files_search_mnt(nginx_t)
files_read_etc_files(nginx_t)
files_read_usr_files(nginx_t)
miscfiles_read_certs(nginx_t)
--
Jérémy
13 years, 1 month
help adding a type attribute to a domain
by Maria Iano
I'm getting a denial that audit2why says is due to constraints.
Sesearch does show that the action has an allow rule.
Here are the audit messages:
host=eng-vocngcn03.eng.gci type=AVC msg=audit(1299844473.770:740848):
avc: denied { sigkill } for pid=22927 comm="kill"
scontext=system_u:system_r:rgmanager_t:s0
tcontext=system_u:system_r:unconfined_t:s0-s0:c0.c1023 tclass=process
host=eng-vocngcn03.eng.gci type=SYSCALL
msg=audit(1299844473.770:740848): arch=c000003e syscall=62 success=yes
exit=0 a0=19ba a1=9 a2=9 a3=0 items=0 ppid=20173 pid=22927
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=4294967295 comm="kill" exe="/bin/kill"
subj=system_u:system_r:rgmanager_t:s0 key=(null)
Here is the result of running sesearch on that same server:
[root@eng-vocngcn03]# sesearch --allow -s rgmanager_t -t unconfined_t -
c process -p sigkill
Found 1 av rules:
allow rgmanager_t unconfined_t : process { sigchld sigkill };
Here is what audit2why says:
[root@eng-vocngcn03]# echo 'host=eng-vocngcn03.eng.gci type=AVC
msg=audit(1299844473.770:740848): avc: denied { sigkill } for
pid=22927 comm="kill" scontext=system_u:system_r:rgmanager_t:s0
tcontext=system_u:system_r:unconfined_t:s0-s0:c0.c1023 tclass=process'
| audit2why
host=eng-vocngcn03.eng.gci type=AVC msg=audit(1299844473.770:740848):
avc: denied { sigkill } for pid=22927 comm="kill"
scontext=system_u:system_r:rgmanager_t:s0
tcontext=system_u:system_r:unconfined_t:s0-s0:c0.c1023 tclass=process
Was caused by:
Constraint violation.
Check policy/constraints.
Typically, you just need to add a type attribute to
the domain to satisfy the constraint.
This is a RHEL 5.5 server and it doesn't have the policy source and I
don't see an rpm available with that. I can't find a constraints file,
and I assume that's because it doesn't have the source. I'm trying to
work out how to add the necessary type attribute to the domain. I do
have a custom policy on the system. It's very long so I'll include the
relevant pieces:
require {
type rgmanager_t;
type unconfined_t;
class process { sigkill signal };
...<snip>...
}
allow rgmanager_t unconfined_t:process sigkill;
...<snip>...
Is there something I can add to my policy to resolve the constraints
issue?
Thanks,
Maria
13 years, 1 month
Re: help adding a type attribute to a domain
by Dominick Grift
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/11/2011 09:47 PM, Maria Iano wrote:
>
> On Mar 11, 2011, at 12:10 PM, Dominick Grift wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 03/11/2011 06:04 PM, Maria Iano wrote:
>>>
>>> On Mar 11, 2011, at 11:48 AM, Dominick Grift wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 03/11/2011 05:42 PM, Daniel J Walsh wrote:
>>>>> On 03/11/2011 10:57 AM, Maria Iano wrote:
>>>>>> I'm getting a denial that audit2why says is due to constraints.
>>>>>> Sesearch does show that the action has an allow rule.
>>>>>
>>>>>> Here are the audit messages:
>>>>>
>>>>>> host=eng-vocngcn03.eng.gci type=AVC
>>>>>> msg=audit(1299844473.770:740848):
>>>>>> avc: denied { sigkill } for pid=22927 comm="kill"
>>>>>> scontext=system_u:system_r:rgmanager_t:s0
>>>>>> tcontext=system_u:system_r:unconfined_t:s0-s0:c0.c1023
>>>>>> tclass=process
>>>>>
>>>>>> host=eng-vocngcn03.eng.gci type=SYSCALL
>>>>>> msg=audit(1299844473.770:740848): arch=c000003e syscall=62
>>>>>> success=yes
>>>>>> exit=0 a0=19ba a1=9 a2=9 a3=0 items=0 ppid=20173 pid=22927
>>>>>> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
>>>>>> fsgid=0 tty=(none) ses=4294967295 comm="kill" exe="/bin/kill"
>>>>>> subj=system_u:system_r:rgmanager_t:s0 key=(null)
>>>>>
>>>>> You have rgmanager sending a kill signal to a process running as
>>>>> unconfined_t
>>>>
>>>> There is no proof that its rgmanager doing that imho. Since
>>>> rgmanager_t
>>>> is an unconfined_domain it could be any generic application started
>>>> by a
>>>> process running in the rgmanager_t domain (eventually started by
>>>> rgmanager)
>>>>
>>>
>>> We have red hat clustering running on the server, and the clustering
>>> processes are running as rgmanager_t. When we move a service off the
>>> server to another node, the clustering software calls a vendor script
>>> like the red hat init.d scripts, with the stop command. That vendor
>>> script calls another script which is a stop script. That stop scripts
>>> if full of kill commands - that match all running processes against
>>> various expressions and kill them.
>>>
>>> We do have a custom policy with a bunch of allow rules but none of
>>> them allow a domain transition.
>>
>> Yes i think i have a reasonable good idea now of what is going on. The
>> easiest solution to the constraint issue would probably be to run
>> rgmanager_t on s0 - mcs_systemhigh.
>>
>> policy_module(myrgmanager, 1.0.0)
>>
>> gen_require(`
>> type rgmanager_t, rgmanager_exec_t;
>> ')
>>
>> init_ranged_daemon_domain(rgmanager_t, rgmanager_exec_t, s0 -
>> mcs_systemhigh)
>>
>> make -f /usr/share/selinux/devel/Makefile myrgmanager.pp
>> sudo semodule -i myrgmanager.pp
>>
>> (may or may not fix the mcs constraint issues)
>>
>>
>
> I added those lines to my .te file and got this error:
>
> [root@eng-vocdeviodb01 ~]# make -f /usr/share/selinux/devel/Makefile
> ngiodb.pp
> Compiling targeted ngiodb module
> /usr/bin/checkmodule: loading policy configuration from tmp/ngiodb.tmp
> ngiodb.te:117:ERROR 'unknown class fd used in rule' at token ';' on line
> 93504:
> allow rgmanager_t unconfined_t:fd use;
> #line 117
> /usr/bin/checkmodule: error(s) encountered while parsing configuration
> make: *** [tmp/ngiodb.mod] Error 1
>
> Am I doing something wrong?
No its probably some el5 quirk. Looks like you would need to require
class fd use;
But i bet that after that then compiler will complain about other
required classes as well.
instead, for now, forget about this solution and try dwalsh'
"mcs_killall(rgmanager_t) solution first. I think that is a bit more
suitable, and if that is not the case we can always resort to my
solution described above later.
echo "policy_module(myrgmanager, 1.0.0) gen_require(\` type rgmanager_t;
') mcs_killall(rgmanager_t)" > myrgmanager.te;
make -f /usr/share/selinux/devel/Makefile myrgmanager.pp
sudo semodule -i myrgmanager.pp
> Thanks,
> Maria
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk16i9sACgkQMlxVo39jgT8pxwCfaLoNtpa5pUfTweZYVGzdYD1W
ZSAAn2ybnQ0vmB0FLG7dnjJf2D5IA09+
=snkC
-----END PGP SIGNATURE-----
13 years, 1 month
denying despite allow rule
by Maria Iano
selinux is denying an action that seems to be allowed in the policy.
Any ideas on why this would be? I want to fix this with a local
policy, but audit2allow just tells me to add the same allow rule that
is already present according to sesearch.
Here are the audit messages:
host=eng-vocngcn03.eng.gci type=AVC msg=audit(1299790809.242:685639):
avc: denied { rename } for pid=21701 comm="vsftpd"
name=".local-110585184.jpg.3836" dev=dm-22 ino=13467775
scontext=system_u:system_r:ftpd_t:s0
tcontext=system_u:object_r:samba_share_t:s0 tclass=file
host=eng-vocngcn03.eng.gci type=SYSCALL
msg=audit(1299790809.242:685639): arch=c000003e syscall=82 success=no
exit=-13 a0=2aca78d2c2a0 a1=2aca78d2c300 a2=1 a3=312d6c61636f6c2f
items=0 ppid=21697 pid=21701 auid=4294967295 uid=14 gid=100 euid=14
suid=14 fsuid=14 egid=100 sgid=100 fsgid=100 tty=(none) ses=4294967295
comm="vsftpd" exe="/usr/sbin/vsftpd" subj=system_u:system_r:ftpd_t:s0
key=(null)
Based on the AVC message I put together and sesearch command below,
and it shows that there is an allow rule:
#sesearch -a -t samba_share_t -s ftpd_t -c file -p rename
Found 1 av rules:
allow ftpd_t samba_share_t : file { ioctl read write create
getattr setattr lock append unlink link rename };
Thanks,
Maria
13 years, 1 month
Re: kernel crash
by Antonio Olivares
--- On Mon, 3/7/11, Adam Williamson <awilliam(a)redhat.com> wrote:
> From: Adam Williamson <awilliam(a)redhat.com>
> Subject: Re: kernel crash
> To: "For testers of Fedora development releases" <test(a)lists.fedoraproject.org>
> Date: Monday, March 7, 2011, 6:02 PM
> On Mon, 2011-03-07 at 17:44 -0800,
> Antonio Olivares wrote:
>
> > This was sent to oops page, but not to fedora
> bugzilla. Is that what the reporting tool should do?
>
> Yes. It's also not a crash, but a warning.
> --
Then why the damn thing says that it is a kernel crash?
If it is just a warning, then the tool should just report an oops right?
BTW, the following sealert keeps popping up and a bug has already been filed :(
It is sadly becoming annoying :(
SELinux is preventing /usr/lib/xulrunner-2/plugin-container from name_connect access on the tcp_socket port 5050.
***** Plugin catchall (100. confidence) suggests ***************************
If you believe that plugin-container should be allowed name_connect access on the port 5050 tcp_socket by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep plugin-containe /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Additional Information:
Source Context unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c
0.c1023
Target Context system_u:object_r:mmcc_port_t:s0
Target Objects port 5050 [ tcp_socket ]
Source plugin-containe
Source Path /usr/lib/xulrunner-2/plugin-container
Port 5050
Host toshiba-satellite
Source RPM Packages xulrunner-2.0-0.25.b12.fc15
Target RPM Packages
Policy RPM selinux-policy-3.9.15-2.fc15
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name toshiba-satellite
Platform Linux toshiba-satellite
2.6.38-0.rc6.git6.1.fc15.i686 #1 SMP Sat Feb 26
02:03:01 UTC 2011 i686 i686
Alert Count 6
First Seen Thu 03 Mar 2011 08:50:35 PM CST
Last Seen Mon 07 Mar 2011 07:55:31 PM CST
Local ID afb8cabc-0526-4409-8185-8412c24eceba
Raw Audit Messages
type=AVC msg=audit(1299549331.536:133): avc: denied { name_connect } for pid=3337 comm="plugin-containe" dest=5050 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mmcc_port_t:s0 tclass=tcp_socket
type=SYSCALL msg=audit(1299549331.536:133): arch=i386 syscall=socketcall success=yes exit=0 a0=3 a1=af4fd080 a2=3729614 a3=0 items=0 ppid=2323 pid=3337 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm=plugin-containe exe=/usr/lib/xulrunner-2/plugin-container subj=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 key=(null)
Hash: plugin-containe,mozilla_plugin_t,mmcc_port_t,tcp_socket,name_connect
audit2allow
#============= mozilla_plugin_t ==============
allow mozilla_plugin_t mmcc_port_t:tcp_socket name_connect;
audit2allow -R
#============= mozilla_plugin_t ==============
allow mozilla_plugin_t mmcc_port_t:tcp_socket name_connect;
https://bugzilla.redhat.com/show_bug.cgi?id=682078
Thanks,
Antonio
13 years, 1 month
recently-used.xbel wrong context
by Trevor Hemsley
Hi
I'm running Centos 5.5 with all the most recent patches applied and am
seeing a strange problem with a file in my home directory called
.recently-used.xbel. It keeps getting the wrong selinux context assigned
to it though I have no idea what is changing it or when.
[trevor@trevor4 ]$ ls -aZl ~/.recently-used.xbel
-rw-rw-r-- 1 user_u:object_r:user_home_dir_t trevor trevor 148481 Feb
18 20:22 /home/trevor/.recently-used.xbel
[trevor@trevor4 ]$ chcon --reference=/home/trevor/.recently-used
~/.recently-used.xbel
[trevor@trevor4 ]$ ls -aZl ~/.recently-used.xbel
-rw-rw-r-- 1 user_u:object_r:user_home_t trevor trevor 148481 Feb
18 20:22 /home/trevor/.recently-used.xbel
It's a file not a directory yet it is being labelled as home_dir_t not
home_t and this causes avc messages. I change it back using the chcon
command above and it stays that way for a while and a few
days/hour/weeks later, it comes back as home_dir_t again. I'm not sure
what it is that triggers the re-mislabelling but I do know that I
'fixed' this via chcon about a week ago and now it's back again and it's
not the first time that this has happened. Looking at these two avcs it
would appear that I 'fixed' it shortly after the 13th and it came back
sometime today or yesterday at a guess.
63. 13/02/11 02:12:53 smbd user_u:system_r:smbd_t:s0 4 file getattr
user_u:object_r:user_home_dir_t:s0 denied 47358
64. 19/02/11 17:39:10 smbd user_u:system_r:smbd_t:s0 4 file getattr
user_u:object_r:user_home_dir_t:s0 denied 54205
[root@trevor4 ~]# ausearch -i -a 54205
----
type=SYSCALL msg=audit(19/02/11 17:39:10.711:54205) : arch=x86_64
syscall=stat success=yes exit=0 a0=7fffe6a808d0 a1=7fffe6a80000
a2=7fffe6a80000 a3=7fffe6a804d0 items=0 ppid=2533 pid=15831 auid=trevor
uid=trevor gid=root euid=trevor suid=root fsuid=trevor egid=trevor
sgid=root fsgid=trevor tty=(none) ses=2 comm=smbd exe=/usr/sbin/smbd
subj=user_u:system_r:smbd_t:s0 key=(null)
type=AVC msg=audit(19/02/11 17:39:10.711:54205) : avc: denied {
getattr } for pid=15831 comm=smbd path=/home/trevor/.recently-used.xbel
dev=dm-5 ino=10453859 scontext=user_u:system_r:smbd_t:s0
tcontext=user_u:object_r:user_home_dir_t:s0 tclass=file
I haven't run a relabel of my system recently and even if I had it
hasn't been since the machine was last rebooted..
[root@trevor4 ~]# uptime
18:10:11 up 52 days, 7:58, 15 users, load average: 0.43, 0.43, 0.25
[root@trevor4 ~]#
[trevor@trevor4 ~]$ rpm -q selinux-policy
selinux-policy-2.4.6-279.el5_5.2
Anyone got any ideas what could be causing this? I can't see anything in
semanage fcontext that could be doing it...
[root@trevor4 ~]# semanage fcontext -l | grep home
/usr/sbin/genhomedircon regular file
system_u:object_r:semanage_exec_t:s0
/usr/lib/oddjob/mkhomedir regular file
system_u:object_r:oddjob_mkhomedir_exec_t:s0
Yours
Baffled of Brighton :)
13 years, 1 month
