Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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:
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.
Last edited by openSauce; 02-04-2009 at 12:58 PM.
Reason: typo
'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.
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
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.
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.
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?
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.