I'm using xdm rather than gdm. SELinux prevents /sbin/pam_console_apply (pam_console_t) "write" to /var/log/xdm.log (var_log_t). It happens once every time someone logs in or out. See the attached mail from SETroubleshoot for an example. To understand what is going on, I tried to strace the processes. But pam_console_apply doesn't attempt to write anything at all! See the attached (compressed) strace from pid 4480, the process mentioned in the SETroubleshoot mail. Xdm has stderr pointing to /var/log/xdm.log, so it's not unlikely that the open fd is inherited by pam_console_apply. But if the inheritance itself was disallowed, wouldn't it be a "use" that would be denied by SELinux rather than a "write"? What am I missing? (The system is not up-to-date. It is possible this message would go away with an upgrade. I'm not looking for a way to get rid of the message here, I'm trying to understand what is going on.)
--- Begin Message ---
- To: goeran@xxxxxxxxxxx
- Subject: [SELinux AVC Alert] SELinux is preventing /sbin/pam_console_apply (pam_console_t) "write" to /var/log/xdm.log (var_log_t).
- From: SELinux_Troubleshoot@xxxxxxxxxxxxxxxxxx
- Date: Sun, 16 Sep 2007 20:11:10 -0000
Summary SELinux is preventing /sbin/pam_console_apply (pam_console_t) "write" to /var/log/xdm.log (var_log_t). Detailed Description SELinux is preventing /sbin/pam_console_apply (pam_console_t) "write" to /var/log/xdm.log (var_log_t). The SELinux type %TARGET_TYPE, is a generic type for all files in the directory and very few processes (SELinux Domains) are allowed to write to this SELinux type. This type of denial usual indicates a mislabeled file. By default a file created in a directory has the gets the context of the parent directory, but SELinux policy has rules about the creation of directories, that say if a process running in one SELinux Domain (D1) creates a file in a directory with a particular SELinux File Context (F1) the file gets a different File Context (F2). The policy usually allows the SELinux Domain (D1) the ability to write or append on (F2). But if for some reason a file (/var/log/xdm.log) was created with the wrong context, this domain will be denied. The usual solution to this problem is to reset the file context on the target file, restorecon -v /var/log/xdm.log. If the file context does not change from var_log_t, then this is probably a bug in policy. Please file a bug report against the selinux-policy package. If it does change, you can try your application again to see if it works. The file context could have been mislabeled by editing the file or moving the file from a different directory, if the file keeps getting mislabeled, check the init scripts to see if they are doing something to mislabel the file. Allowing Access You can attempt to fix file context by executing restorecon -v /var/log/xdm.log
The following command will allow this access:restorecon /var/log/xdm.logAdditional Information
Source Context: system_u:system_r:pam_console_t:SystemLow-SystemHigh Target Context: system_u:object_r:var_log_t Target Objects: /var/log/xdm.log [ file ] Affected RPM Packages: pam-0.99.7.1-5.fc7 [application] Policy RPM: selinux-policy-2.6.4-33.fc7 Selinux Enabled: True Policy Type: targeted MLS Enabled: True Enforcing Mode: Enforcing Plugin Name: plugins.mislabeled_file Host Name: freddi Platform: Linux freddi 2.6.22.1-41.fc7 #1 SMP Fri Jul 27 18:21:43 EDT 2007 x86_64 x86_64 Alert Count: 9 First Seen: Fri Aug 24 19:55:21 2007 Last Seen: Sun Sep 16 22:11:08 2007 Local ID: c7292a43-e2e7-4013-8364-a32c1bacbe9d Line Numbers: Raw Audit Messages :
avc: denied { write } for comm="pam_console_app" dev=sda2 egid=0 euid=0 exe="/sbin/pam_console_apply" exit=0 fsgid=0 fsuid=0 gid=0 items=0 name="xdm.log" path="/var/log/xdm.log" pid=4480 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c1023 sgid=0 subj=system_u:system_r:pam_console_t:s0-s0:c0.c1023 suid=0 tclass=file tcontext=system_u:object_r:var_log_t:s0 tty=(none) uid=0
--- End Message ---
Attachment:
#xdm.4480.bz2
Description: Strace of pam_cansole_apply
-- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
