Fedora Account System
Red Hat Associate
Red Hat Customer
SELinux is preventing /usr/bin/knotify4 from using the 'execstack' accesses on a process. ***** Plugin allow_execstack (53.1 confidence) suggests ******************** If you do not think /usr/bin/knotify4 should need to map stack memory that is both writable and executable. Then you need to report a bug. This is a potentially dangerous access. Do contact your security administrator and report this issue. ***** Plugin catchall_boolean (42.6 confidence) suggests ******************* If you want to allow unconfined executables to make their stack executable. This should never, ever be necessary. Probably indicates a badly coded executable, but could indicate an attack. This executable should be reported in bugzilla Then you must tell SELinux about this by enabling the 'allow_execstack' boolean. Do setsebool -P allow_execstack 1 ***** Plugin catchall (5.76 confidence) suggests *************************** If you believe that knotify4 should be allowed execstack access on processes labeled unconfined_t 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 /usr/bin/knotify4 /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:s0 Target Context unconfined_u:unconfined_r:unconfined_t:s0 Target Objects Unknown [ process ] Source knotify4 Source Path /usr/bin/knotify4 Port <Unknown> Host (removed) Source RPM Packages kdebase-runtime-4.5.4-1.fc14 Target RPM Packages Policy RPM selinux-policy-3.9.7-18.fc14 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 2.6.35.10-74.fc14.i686 #1 SMP Thu Dec 23 16:17:40 UTC 2010 i686 i686 Alert Count 1 First Seen Mon 27 Dec 2010 07:27:12 PM PST Last Seen Mon 27 Dec 2010 07:27:12 PM PST Local ID c19a072c-21b6-4c3f-9ca1-f5fc9813b91a Raw Audit Messages type=AVC msg=audit(1293506832.789:15): avc: denied { execstack } for pid=2092 comm="knotify4" scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process knotify4,unconfined_t,unconfined_t,process,execstack type=SYSCALL msg=audit(1293506832.789:15): arch=i386 syscall=mprotect success=yes exit=0 a0=bfb83000 a1=1000 a2=1000007 a3=bfb81d5c items=0 ppid=1 pid=2092 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm=knotify4 exe=/usr/bin/knotify4 subj=unconfined_u:unconfined_r:unconfined_t:s0 key=(null) knotify4,unconfined_t,unconfined_t,process,execstack #============= unconfined_t ============== #!!!! This avc can be allowed using the boolean 'allow_execstack' allow unconfined_t self:process execstack;
I tried to use the fix recommended in the SELinux Alert Browser (allowing execstack for this particular program). However, following the instructions led to the following: # grep /usr/bin/knotify4 /var/log/audit/audit.log | audit2allow -M knotifypol compilation failed: knotifypol.te:6:ERROR 'syntax error' at token '' on line 6: /usr/bin/checkmodule: error(s) encountered while parsing configuration /usr/bin/checkmodule: loading policy configuration from knotifypol.te knotifypol.te is empty except for the following line: module knotifypol 1.0; and a few blank lines.
I think you have execstack libraries installed on your system You can turn the check off # setsebool -P allow_execstack 1
*** This bug has been marked as a duplicate of bug 652297 ***
Instead, I ran # execstack -c /usr/lib/libxvidcore.so.4 # execstack -c /usr/lib/libxvidcore.so.4.2 since the whole mess started with the upgrade of xvidcore
Thanks I updated https://bugzilla.redhat.com/show_bug.cgi?id=652297 with this information. Please report this to the people who are shipping xvidcore
I have this same problem. And can not get it to work. This new reporting system is the pits for the average user since they are NOT developers and have no clue what they need to do to fix the problem and whether or not it truly is a problem to begin. There has got to be a better way of determining how to report these types of security alerts in a more user friendly way that will give the average user a clue as to what the problem is and if it really is a problem to begin. Even if I tell the system to ignore alerts like this one it still reports them and pops up a message asking what to do. I think most people choose to see what the message is and then are wondering why the alert was even flagged to begin. Just how am I or anyone else that is not a developer supposed to know whether a program is supposed to have access or not. It seems that always allowing programs to do what they want in order to stop the alerts from notifying the user is defeating the whole purpose of having SeLinux running in the first place. In some instances you are told it could be dangerous to allow it or that it may be an attack on your system and in the same instance it asks if you want to enable the program to access what was flagged in the first place. I find this very confusing and I bet many other users do to. So what's the answer, I don't know but the current way of notifying and how to fix it leave a lot to be desired from a users standpoint. There has got to be a better way, maybe listing what the program was actually trying to do could give the user a little bit more insight into what they need to do and whether it needs to be enabled or not. Yes it says it was trying to access the execstack but for what reason. It's all very confusing the way this new alert system is setup and trying to discern what really needs to be done!
I wish we could do better, but you installed a bad library from a non Fedora site that caused the problem. execstack is a fairly dangerous access. Sadly the only choice we have until we find the libary that is causing the problem is to turn the check off. # setsebool -P allow_execstack 1 Currently the kernel only tells us the process that attempted to do the execstack. I have asked the kernel guys to look into whether they could tell us which library asked for the access, which would help us build better diagnosis tools.
Barry which executable did you get the execstack with? If you run ldd on the executable does it list the paths to the libraries. I was thinking I could enhance the plugin to do something like this and check for execstack flag on any library.
Daniel I'll have to watch for the next notification because I don't know what all was running at the time the notification popped up. I prefer not to allow access to this stack so I'm sure it will pop backup again. I think your request to the kernel guys is a good idea. They should be able to at least trace back to the running pid or something that would be helpful in determining what was trying to access the stack. The next time the notification pops up I'll let you know what was running at the time.
Daniel, that maybe worth giving it a try. Let me know where I can grab the update and we can see what happens.
Grab this script from http://people.fedoraproject.org/~dwalsh/SELinux/findexecstack python findexecstack /usr/bin/knotify4 Should list any execstack libraries.
Daniel, I was out for a while and just got back. I copied the script that you created. When does this need to be run? After a notification pops up or do you want me to run it now. I'm assuming you want the files named findexecstack and to run use python findexecstack /usr/bin/knotify4. I don't like to assume because you know what ussually happens. Thanks
No you can run it now to see if it finds anything. But yes the idea is to run it after the alert. Soon, it will become part of the alert and tell the users which libraries are screwed up.
Daniel, thanks for the quick response, not only in creating this add-on but in responding to my initial query about trying to make things easier for the average user. Net message until this new update arrives I will run this and see what it returns. Again, thanks for the quick response to my concerns and the great work in creating an add-on that will help all on deciding what they want to do when presented with an ambiguous notification!