Description of problem: Souhrn: SELinux is preventing gnome-power-man (xdm_t) "execstack" to <Neznámé> (xdm_t). Podrobný popis: SELinux denied access requested by gnome-power-man. It is not expected that this access is required by gnome-power-man 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. Povolení přístupu: 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. Další informace: Kontext zdroje system_u:system_r:xdm_t:SystemLow-SystemHigh Kontext cíle system_u:system_r:xdm_t:SystemLow-SystemHigh Objekty cíle None [ process ] Zdroj gnome-power-man Cesta zdroje /usr/bin/gnome-power-manager Port <Neznámé> Počítač viklef RPM balíčky zdroje gnome-power-manager-2.22.1-1.fc9 RPM balíčky cíle RPM politiky selinux-policy-3.3.1-87.fc9 Selinux povolen True Typ politiky targeted MLS povoleno True Vynucovací režim Enforcing Název zásuvného modulu catchall Název počítače viklef Platforma Linux viklef 2.6.26.3-29.fc9.i686 #1 SMP Wed Sep 3 03:42:27 EDT 2008 i686 i686 Počet upozornění 3 Poprvé viděno Po 8. září 2008, 19:42:29 CEST Naposledy viděno Po 8. září 2008, 23:32:59 CEST Místní ID 51fc65d5-3108-4909-b7d4-20b1e2fc1022 Čísla řádků Původní zprávy auditu host=viklef type=AVC msg=audit(1220909579.16:1025): avc: denied { execstack } for pid=21516 comm="gnome-power-man" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=process host=viklef type=SYSCALL msg=audit(1220909579.16:1025): arch=40000003 syscall=125 success=no exit=-13 a0=bfd91000 a1=1000 a2=1000007 a3=fffff000 items=0 ppid=21508 pid=21516 auid=4294967295 uid=42 gid=42 euid=42 suid=42 fsuid=42 egid=42 sgid=42 fsgid=42 tty=(none) ses=4294967295 comm="gnome-power-man" exe="/usr/bin/gnome-power-manager" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
How did you get this to happen? powermanager should definitely not need execstack.
No idea, meanwhile I switched to RAwhide, so I close this as INSUFFICIENT_DATA, because I won't be able to cooperate o this anymore.
I am also seeing this report. I am running Fedora 9 (i386 version, 32 bit). I don't know what, if anything, the active user (my wife) was doing at the time of the report; she mainly just uses Firefox and Evolution. Source Context: system_u:system_r:xdm_t:s0-s0:c0.c1023 Target Context: system_u:system_r:xdm_t:s0-s0:c0.c1023 Target Objects: None [ process ] Source: gnome-power-man Source Path: /usr/bin/gnome-power-manager Port: <Unknown> Host: baerli Source RPM Packages: gnome-power-manager-2.22.1-1.fc9 Target RPM Packages: Policy RPM: selinux-policy-3.3.1-130.fc9 Selinux Enabled: True Policy Type: targeted MLS Enabled: True Enforcing Mode: Enforcing Plugin Name: catchall Host Name: baerli Platform: Linux baerli 2.6.27.21-78.2.41.fc9.i686 #1 SMP Mon Mar 23 23:45:58 EDT 2009 i686 athlon Alert Count: 36 First Seen: Tue 24 Mar 2009 11:06:44 AM PDT Last Seen: Sat 11 Apr 2009 11:03:46 AM PDT Local ID: 1e7728ab-39bf-40e8-816f-6b0315fb8ad6 Line Numbers: Raw Audit Messages : node=baerli type=AVC msg=audit(1239473026.839:578): avc: denied { execstack } for pid=26893 comm="gnome-power-man" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=process node=baerli type=SYSCALL msg=audit(1239473026.839:578): arch=40000003 syscall=125 success=no exit=-13 a0=bfd7e000 a1=1000 a2=1000007 a3=fffff000 items=0 ppid=26892 pid=26893 auid=4294967295 uid=42 gid=42 euid=42 suid=42 fsuid=42 egid=42 sgid=42 fsgid=42 tty=(none) ses=4294967295 comm="gnome-power-man" exe="/usr/bin/gnome-power-manager" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
nvidia vidio drivers?
No, the box in question has an ATI video card and is using the free software driver (not the ATI closed-source driver). But even if this weren't the case, why would the use of the nvidia video driver make gnome-power-manager try to execute from its stack? Seems more likely that there's a rarely-hit bug.
Please re-open as you now have more data.
Reopening per comment 6
Joe, Look for libraries/binaries marked with the execstack flag find / -exec execstack -q {} \; 2> /dev/null | grep ^X
Ouch! Don't ask people to do that, Daniel. It was hanging for hours when I resorted to lsof to find out what was going on. Not good when it hits /dev (fortunately for me it just hung indefinitely while trying to read /dev/fw0, but reading from devices as root might have unpleasant side-effects). Restricting the search to /usr, /lib, /opt, /bin, and /sbin: X /usr/lib/libxvidcore.so.4 X /usr/lib/libxvidcore.so.4.2 X /usr/share/doc/syslinux-3.61/sample/fd.elf X /usr/share/doc/syslinux-3.61/sample/hello2.elf X /usr/share/doc/syslinux-3.61/sample/filetest.elf X /usr/share/doc/syslinux-3.61/sample/c32echo.elf X /usr/share/doc/syslinux-3.61/sample/hello.elf X /opt/Adobe/Reader9/Reader/intellinux/plug_ins/PPKLite.api X /opt/Adobe/Reader9/Reader/intellinux/lib/libcrypto.so.0.9.8 X /opt/Adobe/Reader9/Reader/intellinux/lib/libcrypto.so.0 X /opt/Adobe/Reader9/Reader/intellinux/lib/libauthplay.so.0.0.0 X /opt/Adobe/Reader9/Reader/intellinux/lib/libcrypto.so X /opt/Adobe/Reader9/Reader/intellinux/lib/libauthplay.so X /opt/Adobe/Reader9/Reader/intellinux/lib/libsccore.so X /opt/Adobe/Reader9/Reader/intellinux/bin/acroread
I got another trigger at 9:51:29 PDT. The time matches up with logs in /var/log/gdm. My wife and I share this machine and use the Gnome user-switcher to go back and forth. The SELinux report time is 9:51:29 and the time of the file /var/log/gdm/:2.log is 9:51:38 (but since that log is written when a new X starts up, which takes a few seconds, it's possible that the X startup is the same time as the SELinux event).
Well I am not sure which one of those libraries is causing the problem, (Or if any). Do you see anything break, or is this just being reported? You can add this access if you choose using audit2allow # grep execstack /var/log/audit/audit.log | audit2allow -M myxdmexecstack # semodule -i myxdmexecstack.pp It could be X starting up, I do not know.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I just upgraded from F9 to F10. I had left myself logged on overnight and when I looked at the machine in the morning setroubleshooter had logged 87 counts of this denial. So it's in F10 at well as F9. I upgraded using preupgrade. #uname -a Linux xxx-ws-053.xxx.local 2.6.27.24-170.2.68.fc10.x86_64 #1 SMP Wed May 20 22:47:23 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.