I am not sure what this is, and /.xauth does not exist, but here is the log: ================================ Summary:
SELinux is preventing su (initrc_su_t) "execute" to ./xauth (xauth_exec_t).
Detailed Description:
SELinux denied access requested by su. It is not expected that this access is required by su and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access.
Allowing Access:
Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for ./xauth,
restorecon -v './xauth'
If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package.
Additional Information:
Source Context system_u:system_r:initrc_su_t:s0 Target Context system_u:object_r:xauth_exec_t:s0 Target Objects ./xauth [ file ] Source su Source Path /bin/su Port <Unknown> Host bronze.cdkkt.com Source RPM Packages coreutils-6.10-25.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-74.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name bronze.cdkkt.com Platform Linux bronze.cdkkt.com 2.6.25.9-76.fc9.i686 #1 SMP Fri Jun 27 16:14:35 EDT 2008 i686 i686 Alert Count 4 First Seen Thu 10 Jul 2008 10:55:02 AM PDT Last Seen Fri 11 Jul 2008 07:37:29 AM PDT Local ID bb7e73a6-b94e-4bf3-9ada-46a9ff2ad486 Line Numbers
Raw Audit Messages
host=bronze.cdkkt.com type=AVC msg=audit(1215787049.815:33): avc: denied { execute } for pid=8831 comm="su" name="xauth" dev=sda6 ino=3121978 scontext=system_u:system_r:initrc_su_t:s0 tcontext=system_u:object_r:xauth_exec_t:s0 tclass=file
host=bronze.cdkkt.com type=SYSCALL msg=audit(1215787049.815:33): arch=40000003 syscall=33 success=no exit=-13 a0=160642 a1=1 a2=161b80 a3=160642 items=0 ppid=8823 pid=8831 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="su" exe="/bin/su" subj=system_u:system_r:initrc_su_t:s0 key=(null)
On Fri, 11 Jul 2008 08:14:21 -0700, Dan Thurman wrote:
I am not sure what this is, and /.xauth does not exist, but here is the log: ================================ Summary:
SELinux is preventing su (initrc_su_t) "execute" to ./xauth (xauth_exec_t).
Detailed Description:
I had that happen on one of my systems too. It was starting a service in init.d that changed userid's via 'su'. Since it was a headless application (i.e. daemon) I chose to ignore the errors as follows:
gen_require(` type initrc_su_t; type sshd_t; type xauth_exec_t; ')
dontaudit initrc_su_t sshd_t:key { search }; dontaudit initrc_su_t xauth_exec_t:file { execute };
As you can see, the 'su' session also tried to grovel around for SSH keys.
C
Carl D. Roth wrote:
On Fri, 11 Jul 2008 08:14:21 -0700, Dan Thurman wrote:
I am not sure what this is, and /.xauth does not exist, but here is the log: ================================ Summary:
SELinux is preventing su (initrc_su_t) "execute" to ./xauth (xauth_exec_t).
Detailed Description:
I had that happen on one of my systems too. It was starting a service in init.d that changed userid's via 'su'. Since it was a headless application (i.e. daemon) I chose to ignore the errors as follows:
gen_require(` type initrc_su_t; type sshd_t; type xauth_exec_t; ')
dontaudit initrc_su_t sshd_t:key { search }; dontaudit initrc_su_t xauth_exec_t:file { execute };
As you can see, the 'su' session also tried to grovel around for SSH keys.
Does it behave better if you use "runuser" instead of "su"?
Paul.
On Fri, 11 Jul 2008 16:57:57 +0100, Paul Howarth wrote:
Carl D. Roth wrote:
On Fri, 11 Jul 2008 08:14:21 -0700, Dan Thurman wrote:
I am not sure what this is, and /.xauth does not exist, but here is the log: ================================ Summary:
SELinux is preventing su (initrc_su_t) "execute" to ./xauth (xauth_exec_t).
Detailed Description:
I had that happen on one of my systems too. It was starting a service in init.d that changed userid's via 'su'. Since it was a headless application (i.e. daemon) I chose to ignore the errors as follows:
gen_require(` type initrc_su_t; type sshd_t; type xauth_exec_t; ')
dontaudit initrc_su_t sshd_t:key { search }; dontaudit initrc_su_t xauth_exec_t:file { execute };
As you can see, the 'su' session also tried to grovel around for SSH keys.
Does it behave better if you use "runuser" instead of "su"?
Paul.
That fixed it, thanks.
C
On Fri, 2008-07-11 at 15:43 +0000, Carl D. Roth wrote:
On Fri, 11 Jul 2008 08:14:21 -0700, Dan Thurman wrote:
I am not sure what this is, and /.xauth does not exist, but here is the log: ================================ Summary:
SELinux is preventing su (initrc_su_t) "execute" to ./xauth (xauth_exec_t).
Detailed Description:
I had that happen on one of my systems too. It was starting a service in init.d that changed userid's via 'su'. Since it was a headless application (i.e. daemon) I chose to ignore the errors as follows:
gen_require(` type initrc_su_t; type sshd_t; type xauth_exec_t; ')
dontaudit initrc_su_t sshd_t:key { search }; dontaudit initrc_su_t xauth_exec_t:file { execute };
As you can see, the 'su' session also tried to grovel around for SSH keys.
If there is a service which runs su in init scripts it should be reported as bug on the package which owns the service. 'runuser' should be used instead of 'su' in init scripts.
selinux@lists.fedoraproject.org