I'm seeing this every hour when the hourly cron job runs
NULL security context for user, but SELinux in permissive mode, continuing ()
I've tried fixfiles but obviously I'm missing something.... Any SELinux gurus that can point me in the right direction? Thanks Rob
Hi,
2009/1/28 Rob Kampen rkampen@kampensonline.com:
I'm seeing this every hour when the hourly cron job runs NULL security context for user, but SELinux in permissive mode, continuing
Try to use "ps -Z" to see if all your processes have appropriate security contexts. It's unlikely (impossible?) that one of them will not have, but start with that anyway.
Also you can use "ls -Z" to see if the files have security contexts or not. Maybe start with "ls -Z /etc/cron*" and "ls -Z /var/spool/cron/" to see if the files related to crontabs are covered.
Also have a look at what "semanage login -l" returns, in CentOS you should have an entry for "__default__" pointing to "user_u" and one for "root" pointing to "root".
I've tried fixfiles but obviously I'm missing something....
Sometimes fixfiles will not be able to do a thorough job if your system is booted and running. It's preferrable to do "touch /.autorelabel" and reboot the machine, that way "fixfiles" will run as the only process in the machine and will be able to label all files properly.
Any SELinux gurus that can point me in the right direction?
Far from being a guru, but maybe the information above will be useful for you to hunt the problem down.
HTH, Filipe
Filipe Brandenburger wrote:
Hi,
2009/1/28 Rob Kampen rkampen@kampensonline.com:
I'm seeing this every hour when the hourly cron job runs NULL security context for user, but SELinux in permissive mode, continuing
Try to use "ps -Z" to see if all your processes have appropriate security contexts. It's unlikely (impossible?) that one of them will not have, but start with that anyway.
All OK
Also you can use "ls -Z" to see if the files have security contexts or not. Maybe start with "ls -Z /etc/cron*" and "ls -Z /var/spool/cron/" to see if the files related to crontabs are covered.
Also have a look at what "semanage login -l" returns, in CentOS you should have an entry for "__default__" pointing to "user_u" and one for "root" pointing to "root".
All ok
I've tried fixfiles but obviously I'm missing something....
Sometimes fixfiles will not be able to do a thorough job if your system is booted and running. It's preferrable to do "touch /.autorelabel" and reboot the machine, that way "fixfiles" will run as the only process in the machine and will be able to label all files properly.
Last resort was the 'touch /.autorelabel' and reboot. This took nearly an hour but once it came up all was well. Thanks for the pointers Filipe. At what point would it be safe to go to enforcing? What logs should I be inspecting for warnings? I find SELinux real hard to get my head around, extensive reading and still I don't get it clearly enough to where I understand it and feel safe committing my business server to it. And when something like this occurs and it takes the server down for an hour to clean it up.... not really production ready. I'm getting ready to head for PCI-DSS audit and thought SELinux enforcing would be a help......any comments from those with more experience??
Any SELinux gurus that can point me in the right direction?
Far from being a guru, but maybe the information above will be useful for you to hunt the problem down.
HTH, Filipe _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Wed, 2009-01-28 at 23:00 -0500, Rob Kampen wrote:
Last resort was the 'touch /.autorelabel' and reboot. This took nearly an hour but once it came up all was well. Thanks for the pointers Filipe. At what point would it be safe to go to enforcing? What logs should I be inspecting for warnings? I find SELinux real hard to get my head around, extensive reading and still I don't get it clearly enough to where I understand it and feel safe committing my business server to it. And when something like this occurs and it takes the server down for an hour to clean it up.... not really production ready. I'm getting ready to head for PCI-DSS audit and thought SELinux enforcing would be a help......any comments from those with more experience??
---- you shouldn't have to relabel a filesystem unless you had turned SELinux off for a while. So that shouldn't be necessary again.
I also gathered that the RHEL 5.3 release has a bunch of the newer tools from virtually current Fedora like SETroubleShooter which should make life a lot easier.
I gather that CentOS 5.3 will be released in the next week or so and I would probably wait until you have it running fine for a week or two in permissive mode and have squashed any alerts and you should be good to move to enforcing.
Craig
Craig White wrote:
On Wed, 2009-01-28 at 23:00 -0500, Rob Kampen wrote:
Last resort was the 'touch /.autorelabel' and reboot. This took nearly an hour but once it came up all was well. Thanks for the pointers Filipe. At what point would it be safe to go to enforcing? What logs should I be inspecting for warnings? I find SELinux real hard to get my head around, extensive reading and still I don't get it clearly enough to where I understand it and feel safe committing my business server to it. And when something like this occurs and it takes the server down for an hour to clean it up.... not really production ready. I'm getting ready to head for PCI-DSS audit and thought SELinux enforcing would be a help......any comments from those with more experience??
you shouldn't have to relabel a filesystem unless you had turned SELinux off for a while. So that shouldn't be necessary again.
I also gathered that the RHEL 5.3 release has a bunch of the newer tools from virtually current Fedora like SETroubleShooter which should make life a lot easier.
I gather that CentOS 5.3 will be released in the next week or so and I would probably wait until you have it running fine for a week or two in permissive mode and have squashed any alerts and you should be good to move to enforcing.
Craig
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I have five other machines that will be updated to 5.3 prior to risking this server, once they're all going okay I'll move to this one. Thanks for the pointers Craig. One thing I have learned is that mv is not very safe, cp is better - particularly across directories. I will need to play with SETroubleShooter. I have not used SELinux on my work-stations / laptops, and only leave it in permissive mode on my servers, thus I don't really have somewhere to play with it. Does anyone use SELinux on their work-station i.e. the place where you try things out, debug things etc?? or is it really only for stable systems where not many OS changes and new program trials occur? I know that asterisk doesn't play nice with SELinux, even in permissive mode it fails to work, and yet this is one area where I would like to have it work as my phone system is VITAL to my business! Thanks Rob
On 1/29/09, Rob Kampen rkampen@kampensonline.com wrote: .
Does anyone use SELinux on their work-station i.e. the place where you try things out, debug things etc?? or is it really only for stable systems where not many OS changes and new program trials occur? I know that asterisk doesn't play nice with SELinux, even in permissive mode it fails to work, and yet this is one area where I would like to have it work as my phone system is VITAL to my business! Thanks Rob
We use SELinux on both our workstations and our servers. We run them in permissive mode for a while, do our testing and then switch to enforcing once we have cleared up any denials. Run tests then if it all looks good , put the boxen into production. Audit2allow and other such tools are very useful in creating any policy changes that you require and the selinux mailling lists are helpful as well. The main thing i have been caught out with is when using tftp to transfer configs from our cisco kit to my workstation in that when i touch the file i need to set the correct context for it.
Russell Coker's site is a good place for selinux info
http://www.coker.com.au/selinux/
mike
-
Craig White -
Filipe Brandenburger -
Michael Simpson -
Rob Kampen