selinux using all my cpu

openSauce · 02-01-2009, 05:52 AM

Hi,

I've been using Fedora 10 i686 for a few months. In the past week or so, selinux has started a process at boot time which eats up a lot of my resources.

For five minutes or so, setroubleshootd uses 50-70% of CPU time, and after that /usr/bin/sealer takes over and uses 70-90% of CPU until I kill it. I don't get any SELinux alerts in the Gnome notification area when this is going on, or any other visible indication of what might be happening.

grepping /var/log/messages forsetroubleshoot reveals the following messages for today:

Code:

Feb  1 11:16:20 mer39 setroubleshoot: [rpc.ERROR] attempt to open server connection failed: No such file or directory
Feb  1 11:30:25 mer39 setroubleshoot: [rpc.ERROR] could not send data on socket ({unix}/var/run/setroubleshoot/setroubleshoot_server socket=0xb7a05a3c): Broken pipe

But nothing on /var/log/secure, and nothing if I grep for sealer. Can anyone help me diagnose what's going on? Also, is there a security risk in killing the sealer process and not starting it up again?

Only other thing I can see that might be relevant is that during the first few mins when setroubleshootd is the cpu hog, mount.ntfs is also using about 20% of cpu, and this dies down when sealer takes over. Something to do with one of my ntfs partitions maybe? Here are the ntfs-related lines from fstab:

Code:

/dev/sda2               /mnt/win                ntfs    ro,noauto,users,exec 0 2
UUID=28A8172AA816F652   /mnt/data               ntfs    exec,uid=500,gid=500,dmask=0077,fmask=0177,users 0 0
/mnt/data/.mer39	/home/openSauce/mer39-local	ext3	defaults,loop,users,exec,noauto	0 0

The third line is not an ntfs filesystem, it's an ext3 one inside a file sitting on an ntfs system, but this did cause selinux some issues until I set the noauto option so I've included it just in case.

unSpawn · 02-01-2009, 08:04 PM

Quote:

Originally Posted by openSauce

/usr/bin/sealer

'top' cuts off process names, so this probably is 'sealert'. As long as the Audit daemon is running the AVC messages should be in /var/log/audit/audit.log unless F10 changed things. The socket error looks like odd. Did you change anything in /etc/setroubleshoot/setroubleshoot.cfg or with Python or access rights on /var/run? (Or anything else you should mention?) Does verifying the setroubleshoot-server package show anything? Since you run F10 you might also want to check out Fedora bug tracker. Maybe you're not the first one to encouter the problem.

openSauce · 02-02-2009, 07:48 AM

Quote:

Originally Posted by unSpawn

Did you change anything in /etc/setroubleshoot/setroubleshoot.cfg or with Python or access rights on /var/run?

No. I think ls -l is the right command to use to find out modification time; /etc/setroubleshoot/setroubleshoot.cfg was last modified Feb 2008. Permissions/ownership on /var/run are 755 root:root.

Quote:

Originally Posted by unSpawn

(Or anything else you should mention?)

I've tried to allow logrotate access to files in my home directory and root's home directory, and selinux has been causing some issues. I've relabelled the files to var_log_t using the SELinux Management gui tool, followed by restorecon. This stopped SELinux alerts appearing in the Gnome notification area, but logrotate still isn't rotating the log files. logrotate is mentioned in the audit log, maybe this is the root of the problem.

I'm not sure exactly what gets put in audit.log or how to read it; I noticed it logged uses of sudo, so below is the output of
sudo grep -v sudo /var/log/audit/audit.log | tail

Code:

type=AVC msg=audit(1233575326.192:33): avc:  denied  { read } for  pid=7802 comm="logrotate" name="openSauce" dev=sda1 ino=1860482 scontext=system_u:system_r:logrotate_t:s0 tcontext=system_u:object_r:user_home_dir_t:s0 tclass=dir
type=SYSCALL msg=audit(1233575326.192:33): arch=40000003 syscall=5 success=no exit=-13 a0=bfa01d10 a1=98800 a2=d a3=0 items=0 ppid=7800 pid=7802 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="logrotate" exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0 key=(null)
type=AVC msg=audit(1233575326.223:34): avc:  denied  { write } for  pid=7802 comm="logrotate" name="openSauce" dev=sda1 ino=1860482 scontext=system_u:system_r:logrotate_t:s0 tcontext=system_u:object_r:user_home_dir_t:s0 tclass=dir
type=SYSCALL msg=audit(1233575326.223:34): arch=40000003 syscall=38 success=no exit=-13 a0=936f340 a1=9371460 a2=936cdf0 a3=bfa02118 items=0 ppid=7800 pid=7802 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="logrotate" exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0 key=(null)
type=USER_CMD msg=audit(1233580686.579:38): user pid=10388 uid=0 auid=500 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/home/openSauce" cmd=2F62696E2F6C73202F7661722F6C6F672F61756469742F (terminal=pts/2 res=success)'
type=USER_CMD msg=audit(1233580696.237:42): user pid=10393 uid=0 auid=500 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/home/openSauce" cmd=2F7573722F62696E2F6C657373202F7661722F6C6F672F61756469742F61756469742E6C6F67 (terminal=pts/2 res=success)'
type=USER_CMD msg=audit(1233580800.842:46): user pid=10452 uid=0 auid=500 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/home/openSauce" cmd=2F7573722F62696E2F7461696C202F7661722F6C6F672F61756469742F61756469742E6C6F67 (terminal=pts/2 res=success)'
type=USER_CMD msg=audit(1233580879.015:52): user pid=10515 uid=0 auid=500 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/home/openSauce" cmd=2F62696E2F67726570203130343532202F6574632F736861646F77 (terminal=pts/1 res=success)'
type=USER_CMD msg=audit(1233580884.840:56): user pid=10530 uid=0 auid=500 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/home/openSauce" cmd=2F62696E2F67726570203130333933202F6574632F736861646F77 (terminal=pts/1 res=success)'
type=USER_CMD msg=audit(1233580915.665:60): user pid=10542 uid=0 auid=500 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/home/openSauce" cmd=2F62696E2F67726570202D76207375646F202F7661722F6C6F672F61756469742F61756469742E6C6F67 (terminal=pts/2 res=success)'

It looks like maybe the problem is that although the files are labelled correctly, they sit in a directory with the label user_home_dir_t. This didn't cause problems on my other machine running F9, but does that sound like it might be the issue?

Quote:

Originally Posted by unSpawn

Does verifying the setroubleshoot-server package show anything?

I guess you're talking about rpm -verify setroubleshoot-server. This command produced no output.

unSpawn · 02-03-2009, 05:03 PM

Quote:

Originally Posted by openSauce

I'm not sure exactly what gets put in audit.log or how to read it

audit.log contains the Access Vector Cache (AVC) messages the kernel emits. It the Audit daemon isn't running then it gets dumped to syslog. The easiest way (unless you have specific interests) to "read" the logfile is to just feed it to 'audit2allow'. Your excerpt only gets me one suggestion for local policy modification for "logrotate_t": "allow logrotate_t user_home_dir_t:dir { read write };".

Quote:

Originally Posted by openSauce

It looks like maybe the problem is that although the files are labelled correctly, they sit in a directory with the label user_home_dir_t. This didn't cause problems on my other machine running F9, but does that sound like it might be the issue?

I doubt that would mitigate more pressing error messages like you "could not send data on socket ({unix}/var/run/setroubleshoot/setroubleshoot_server socket=0xb7a05a3c): Broken pipe". Could you check /var/run/setroubleshoot/setroubleshoot_server? It should have octal mode 0666 and context system_u, object_r, setroubleshoot_var_run_t. I'm hesitant to suggest trying to "fix" things by reinstalling services, so I'd like to try any other options first. Could you please check other logfiles (already logrotated) for anything related to setroubleshootd and or sealert? Does the setroubleshootd (already logrotated) logs show anything? Please also check out Fedora bug tracker.

openSauce · 02-04-2009, 01:05 PM

I seem to have fixed the original problem: it turned out I hadn't actually relabelled the log file in root's home dir, now that I've done this, sealert doesn't hog the cpu, and the file's in my home dir are being rotated.

I'm not sure what to do about the broken pipe error, /var/run/setroubleshoot/setroubleshoot_server has correct permissions and context, but it doesn't seem to be causing any issues with day-to-day usage, so I might just leave it for now, unless you think it could be a security risk?

Thanks for your time

unSpawn · 02-05-2009, 05:03 PM

Quote:

Originally Posted by openSauce

I seem to have fixed the original problem: it turned out I hadn't actually relabelled the log file in root's home dir, now that I've done this, sealert doesn't hog the cpu, and the file's in my home dir are being rotated.

Well done!

Quote:

Originally Posted by openSauce

I'm not sure what to do about the broken pipe error, /var/run/setroubleshoot/setroubleshoot_server has correct permissions and context, but it doesn't seem to be causing any issues with day-to-day usage, so I might just leave it for now, unless you think it could be a security risk?

Knowing the kernel dumps AVC messages regardless, and knowing 'rpm -qi setroubleshoot-server' only says "Provides tools to help diagnose SELinux problems" I wouldn't say it's a security problem if you get alerted and react to AVC warnings in another way but it's a malfunction nonetheless. Could you again check if all services (like DBUS) are running, and if anything related to Python, whatever-XML, setroubleshoot(-server) has changed (maybe 'rpm -qVa' for an overview)? And please do check the Fedora bugtracker.