Hi,
total newbie on CentOS. Just firing up an install of 5.5 on a development webserver. Installed Webmin, Awstats, PHPMyAdmin and Drupal successfully. Yet to work on Sendmail and Samba. SELinux in enforcing mode, reporting "SELinux preventing ifconfig (ifconfig_t) "read write" to /var/webminsessiondb.pag (var_t)".
Googled the error message without real success in finding fix - bug reports showing. Question is whether worth pursuing as SELinux is the way of the future. Or is SELinux a good idea that never really made it's way into the sun. Thoughts please.
Alison PS. Semi-retired. Cut my teeth as sys prog on RSX11-M systems eons ago.
2010/11/27 Alison penguin@alisoncc.com:
Hi,
total newbie on CentOS. Just firing up an install of 5.5 on a development webserver. Installed Webmin, Awstats, PHPMyAdmin and Drupal successfully. Yet to work on Sendmail and Samba. SELinux in enforcing mode, reporting "SELinux preventing ifconfig (ifconfig_t) "read write" to /var/webminsessiondb.pag (var_t)".
Googled the error message without real success in finding fix - bug reports showing. Question is whether worth pursuing as SELinux is the way of the future. Or is SELinux a good idea that never really made it's way into the sun. Thoughts please.
Just turn selinux off. setenforce "0" works without rebooting server, but /etc/sysconfig/selinux is correct place to finalize setting..
-- Eero
On Sat, Nov 27, 2010 at 02:53:30AM +0200, Eero Volotinen wrote:
Just turn selinux off. setenforce "0" works without rebooting server, but /etc/sysconfig/selinux is correct place to finalize setting..
Oh please. This is perhaps the most idiotic advice I've seen on this list in months.
John
On 11/27/2010 01:53 AM, Eero Volotinen wrote:
2010/11/27 Alisonpenguin@alisoncc.com:
Hi,
total newbie on CentOS. Just firing up an install of 5.5 on a development webserver. Installed Webmin, Awstats, PHPMyAdmin and Drupal successfully. Yet to work on Sendmail and Samba. SELinux in enforcing mode, reporting "SELinux preventing ifconfig (ifconfig_t) "read write" to /var/webminsessiondb.pag (var_t)".
Googled the error message without real success in finding fix - bug reports showing. Question is whether worth pursuing as SELinux is the way of the future. Or is SELinux a good idea that never really made it's way into the sun. Thoughts please.
Just turn selinux off. setenforce "0" works without rebooting server, but /etc/sysconfig/selinux is correct place to finalize setting..
What's with people recommending to turn off SELinux?! That's just bad advice and like recommending people keep their doors unlocked at all times. Really, stop doing that. SELinux is there for a reason.
Afaik Webmin does not have a very good reputation when it comes to security. With that in mind your advice makes Alison's box much more vulnerable.
My advice to Alison is to remove Webmin and use the tools that come with CentOS 5.5. Also make sure that phpMyAdmin can only be accessed from your local LAN, use strong passwords, turn on a tight firewall and do anything else that one should do to keep the bad guys from gaining illegal access to your server.
The NSA has some nice guides how to keep your server secure. The guides are on this page: http://www.nsa.gov/ia/guidance/security_configuration_guides/operating_syste...
Regards, Patrick
Just turn selinux off. setenforce "0" works without rebooting server, but /etc/sysconfig/selinux is correct place to finalize setting..
What's with people recommending to turn off SELinux?! That's just bad advice and like recommending people keep their doors unlocked at all times. Really, stop doing that. SELinux is there for a reason.
Usually it causes more problems. If you have unlimited resources to tune it up, then it possibly helps on the way.
My advice to Alison is to remove Webmin and use the tools that come with CentOS 5.5. Also make sure that phpMyAdmin can only be accessed from your local LAN, use strong passwords, turn on a tight firewall and do
.. and disable password authentication on sshd server.
anything else that one should do to keep the bad guys from gaining illegal access to your server.
The NSA has some nice guides how to keep your server secure. The guides are on this page: http://www.nsa.gov/ia/guidance/security_configuration_guides/operating_syste...
http://www.zlinuxtoday.com/z/wp-content/uploads/2010/06/CIS_RHEL_5.0-5.1_Ben...
-- Eero
On Sat, Nov 27, 2010 at 03:29:49AM +0200, Eero Volotinen wrote:
Usually it causes more problems. If you have unlimited resources to tune it up, then it possibly helps on the way.
Only if you don't bother to take the time to read any of the resources I previously provided or any of the other SElinux resources available on the 'net.
SElinux is not brain surgery; spend some time with the documentation and you'll be surprised at how easily it all comes together after a while.
Telling people to disable it is not only foolish but completely irresponsible; doubly so in a medium that exists to support users. If the best avenue was to disable it do you honestly think that upstream would enable it by default?
This is 2010 - people are expected to actually make an effort at learning the systems they so casually throw up on the 'net and to take responsibility for those systems. Every time a box gets compromised it can pose a risk to the rest of us; please be mature and responsible enough to make it as difficult as possible to permit such a compromise in the first place.
John
On 11/26/10 8:01 PM, John R. Dennison wrote:
If the best avenue was to disable it do you honestly think that upstream would enable it by default?
They are, after all, selling service. What distro enables it that doesn't have a service for pay model (besides Centos, which just inherits it)?
Thanks for all the input. Particularly John and Patricks URL's for reading material. Starting with the stuff here http://www.nsa.gov/ia/guidance/security_configuration_guides/operating_syste... Which is really good.
I can get 1.5Mb/s upload using Annex M, but have previously purchased hosting as I have had little experience in "battle hardening" a server. Feeling much more confident now that I have reading material to guide me in keeping the bad guys out.
Alison
At 01:01 PM 27/11/2010, you wrote:
On Sat, Nov 27, 2010 at 03:29:49AM +0200, Eero Volotinen wrote:
Usually it causes more problems. If you have unlimited resources to tune it up, then it possibly helps on the way.
Only if you don't bother to take the time to read any of the resources I previously provided or any of the other SElinux resources available on the 'net. SElinux is not brain surgery; spend some time with the documentation and you'll be surprised at how easily it all comes together after a while. Telling people to disable it is not only foolish but completely irresponsible; doubly so in a medium that exists to support users. If the best avenue was to disable it do you honestly think that upstream would enable it by default? This is 2010 - people are expected to actually make an effort at learning the systems they so casually throw up on the 'net and to take responsibility for those systems. Every time a box gets compromised it can pose a risk to the rest of us; please be mature and responsible enough to make it as difficult as possible to permit such a compromise in the first place. John-- Live a good life. If there are gods and they are just, they will not care how devout you have been, but will welcome you based on the virtues you have lived by. If there are gods, but unjust, then you should not want to worship them. If there are no gods, then you will be gone, but will have lived a noble life that will live on in the memories of your loved ones.
-- Marcus Aurelius (121-180), philosopher and writer
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 27/11/10 06:33, Alison wrote:
Thanks for all the input. Particularly John and Patricks URL's for reading material. Starting with the stuff here http://www.nsa.gov/ia/guidance/security_configuration_guides/operating_syste... Which is really good.
There is also a guide to SELinux on the CentOS Wiki:
http://wiki.centos.org/HowTos/SELinux
Hope that helps.
Thanks for all the input. Particularly John and Patricks URL's for reading material. Starting with the stuff here http://www.nsa.gov/ia/guidance/security_configuration_guides/operating_syste... Which is really good.
Verry interesting collection. The document for rhel5 is verry well written. I disagree on certain aspects, but I will certainly learn from it.
On 11/26/2010 05:17 PM, Patrick Lists wrote:
What's with people recommending to turn off SELinux?! That's just bad advice and like recommending people keep their doors unlocked at all times. Really, stop doing that. SELinux is there for a reason.
SELinux is like a automatic collision avoidance system for an airplane that unpredictably crashes the plane during normal flight. While the basic idea is good, until it stops crashing planes without warning it isn't going to be accepted.
It is not enough that it mitigates certain classes of attacks when it actively breaks running systems *more often* than it mitigates attacks. And that is my personal experience. Every year or two I try turning it on on a few systems. And then, after it suddenly decides to break a previously stable system - it gets turned back off.
On 27/11/10 18:57, Benjamin Franz wrote:
On 11/26/2010 05:17 PM, Patrick Lists wrote:
What's with people recommending to turn off SELinux?! That's just bad advice and like recommending people keep their doors unlocked at all times. Really, stop doing that. SELinux is there for a reason.
SELinux is like a automatic collision avoidance system for an airplane that unpredictably crashes the plane during normal flight. While the basic idea is good, until it stops crashing planes without warning it isn't going to be accepted.
It is not enough that it mitigates certain classes of attacks when it actively breaks running systems *more often* than it mitigates attacks. And that is my personal experience. Every year or two I try turning it on on a few systems. And then, after it suddenly decides to break a previously stable system - it gets turned back off.
This is where, as a sysadmin, you need to invest just a little time and effort learning the system. Honestly, the vast majority of issues are trivial to solve if you just spend a few hours reading the docs/guides, and even if you really can't be bothered there are kind folks on this list (and others) that will likely solve your issues for you. How is that not worth the extra security SELinux affords?
On Saturday 27 November 2010 18:57:50 Benjamin Franz wrote:
On 11/26/2010 05:17 PM, Patrick Lists wrote:
What's with people recommending to turn off SELinux?! That's just bad advice and like recommending people keep their doors unlocked at all times. Really, stop doing that. SELinux is there for a reason.
SELinux is like a automatic collision avoidance system for an airplane that unpredictably crashes the plane during normal flight. While the basic idea is good, until it stops crashing planes without warning it isn't going to be accepted.
I don't understand this analogy. I have never seen SELinux crashing the system or doing some damage otherwise. What experience do you have with SELinux crashing anything on a working system?
It is not enough that it mitigates certain classes of attacks when it actively breaks running systems *more often* than it mitigates attacks. And that is my personal experience. Every year or two I try turning it on on a few systems. And then, after it suddenly decides to break a previously stable system - it gets turned back off.
If your system was running for some time with SELinux disabled (not in permissive mode, but disabled), turning it on without doing a proper relabeling of the filesystem is known to be a very Bad Idea. Typically all problems that occur in this situation can be eliminated by relabeling the whole filesystem once. Maybe that was the step you missed?
HTH, :-) Marko
On Sat, Nov 27, 2010 at 5:52 PM, Marko Vojinovic vvmarko@gmail.com wrote:
On Saturday 27 November 2010 18:57:50 Benjamin Franz wrote:
On 11/26/2010 05:17 PM, Patrick Lists wrote:
What's with people recommending to turn off SELinux?! That's just bad advice and like recommending people keep their doors unlocked at all times. Really, stop doing that. SELinux is there for a reason.
SELinux is like a automatic collision avoidance system for an airplane that unpredictably crashes the plane during normal flight. While the basic idea is good, until it stops crashing planes without warning it isn't going to be accepted.
I don't understand this analogy. I have never seen SELinux crashing the system or doing some damage otherwise. What experience do you have with SELinux crashing anything on a working system?
The "working system" in that analogy is software, not necessarily nor even likely to be the kernel itself. But yes, it can trash a production critical web or software application that didn't follow the sensible, but often poorly understood, policies of SELinux. This is particularly common with 3rd party web applications, the sort of thing we grab from Sourceforge and try ourselves. (Lilac, the Nagios configuration tool, particularly comes to mind.)
It is not enough that it mitigates certain classes of attacks when it actively breaks running systems *more often* than it mitigates attacks. And that is my personal experience. Every year or two I try turning it on on a few systems. And then, after it suddenly decides to break a previously stable system - it gets turned back off.
If your system was running for some time with SELinux disabled (not in permissive mode, but disabled), turning it on without doing a proper relabeling of the filesystem is known to be a very Bad Idea. Typically all problems that occur in this situation can be eliminated by relabeling the whole filesystem once. Maybe that was the step you missed?
I'd have to dig back to rediscover the Lilac issues, but I remember running out of time to sort them all out and having to leave SELinux off of that server.
On Sat, Nov 27, 2010 at 08:23:34PM -0500, Nico Kadel-Garcia wrote:
The "working system" in that analogy is software, not necessarily nor even likely to be the kernel itself. But yes, it can trash a production critical web or software application that didn't follow the sensible, but often poorly understood, policies of SELinux. This is particularly common with 3rd party web applications, the sort of thing we grab from Sourceforge and try ourselves. (Lilac, the Nagios configuration tool, particularly comes to mind.)
I'd have to dig back to rediscover the Lilac issues, but I remember running out of time to sort them all out and having to leave SELinux off of that server.
heh, fail.
You run it in Permissive mode, you deal with the exceptions as they arise while the software is running in its normal environment and while its running normally using any of the documented methods. You thoroughly test the application in such a manner and once you have ironed out any and all issues by putting together a custom policy, setting the right SElinux booleans, etc, you then enable Enforcing mode. There is really no reason that SElinux should have a negative impact on your application or server if you use Permissive first.
John
On Sat, Nov 27, 2010 at 9:21 PM, John R. Dennison jrd@gerdesas.com wrote:
On Sat, Nov 27, 2010 at 08:23:34PM -0500, Nico Kadel-Garcia wrote:
The "working system" in that analogy is software, not necessarily nor even likely to be the kernel itself. But yes, it can trash a production critical web or software application that didn't follow the sensible, but often poorly understood, policies of SELinux. This is particularly common with 3rd party web applications, the sort of thing we grab from Sourceforge and try ourselves. (Lilac, the Nagios configuration tool, particularly comes to mind.)
I'd have to dig back to rediscover the Lilac issues, but I remember running out of time to sort them all out and having to leave SELinux off of that server.
heh, fail.
You run it in Permissive mode, you deal with the exceptions as they arise while the software is running in its normal environment and while its running normally using any of the documented methods. You thoroughly test the application in such a manner and once you have ironed out any and all issues by putting together a custom policy, setting the right SElinux booleans, etc, you then enable Enforcing mode. There is really no reason that SElinux should have a negative impact on your application or server if you use Permissive first.
You forgot "take on becoming the SELinux integration manager for that project with every single update". I've done that several times now (and had to step back when the software had major revisions and I no longer had project time for it). It was a complete waste of my engineering time and testing cycles, because the upstream authors simply had no interest or involvement in keeping things consistently laid out for SELinux integration.
My time was better spent on things like getting the software into 64-bit compatibility and re-arranging it to get it RPM bundled. (I do a lot of that!!!)
You forgot "take on becoming the SELinux integration manager for that project with every single update". I've done that several times now
In commercial service production, wasted time also costs money.
I think it is easier/cheaper to use hardware firewalls and idp systems to protect servers than fight with selinux on each server.
SELinux tuning might work on companies with unlimited resources like NSA .. or if you run server at home with unlimited free time to tune it up.
-- Eero
On Sunday 28 November 2010 11:22:14 Eero Volotinen wrote:
You forgot "take on becoming the SELinux integration manager for that project with every single update". I've done that several times now
In commercial service production, wasted time also costs money.
I think it is easier/cheaper to use hardware firewalls and idp systems to protect servers than fight with selinux on each server.
SELinux tuning might work on companies with unlimited resources like NSA .. or if you run server at home with unlimited free time to tune it up.
This is just FUD. If SELinux yells at you, you have an insecure system, period. Deal with that, not with SELinux.
If you deliberately want to keep your system insecure, modify local SELinux policy to allow access. It is enough to do it just once, or at least until you reinstall the OS on the machine.
It just takes a minimal investment of time to learn how to interact with SELinux. And any serious sysadmin should learn it.
Best, :-) Marko
On Sunday, November 28, 2010 07:22 PM, Eero Volotinen wrote:
You forgot "take on becoming the SELinux integration manager for that project with every single update". I've done that several times now
In commercial service production, wasted time also costs money.
I think it is easier/cheaper to use hardware firewalls and idp systems to protect servers than fight with selinux on each server.
SELinux tuning might work on companies with unlimited resources like NSA .. or if you run server at home with unlimited free time to tune it up.
Are you some secret agent for botnets? I know they love to get their hands on Linux boxes for use as their command centres for their Windows drones.
On Sun, Nov 28, 2010 at 09:14:43PM +0800, Christopher Chan wrote:
I think it is easier/cheaper to use hardware firewalls and idp systems to protect servers than fight with selinux on each server.
SELinux tuning might work on companies with unlimited resources like NSA .. or if you run server at home with unlimited free time to tune it up.
Are you some secret agent for botnets? I know they love to get their hands on Linux boxes for use as their command centres for their Windows drones.
Sigh. I don't think people have the right (or ability) to judge another person's situation.
So....
Judging from this, every AIX, Solaris, and BSD administrator are botnet agents. As well as Debian server farms.
On Sunday, November 28, 2010 10:50 PM, Scott Robbins wrote:
On Sun, Nov 28, 2010 at 09:14:43PM +0800, Christopher Chan wrote:
I think it is easier/cheaper to use hardware firewalls and idp systems to protect servers than fight with selinux on each server.
SELinux tuning might work on companies with unlimited resources like NSA .. or if you run server at home with unlimited free time to tune it up.
Are you some secret agent for botnets? I know they love to get their hands on Linux boxes for use as their command centres for their Windows drones.
Sigh. I don't think people have the right (or ability) to judge another person's situation.
So....
Judging from this, every AIX, Solaris, and BSD administrator are botnet agents. As well as Debian server farms.
If they are die-hard don't lock down because it's too troublesome chaps then yeah!
Two other schools got their box hacked through phpmyadmin because the chap at HQ failed to locked down. I had to show him how to turn on SELinux and also figure out from the logs how the bot was uploaded.
I had never done SELinux before that but I got it mostly sorted within a morning and completely sorted in two days for some stuff that did not initially show up. This was a Moodle box with a mysql backend.
I, therefore, cannot see any excuse for disabling SELinux.
On Sunday 28 November 2010 03:45:54 Nico Kadel-Garcia wrote:
On Sat, Nov 27, 2010 at 9:21 PM, John R. Dennison jrd@gerdesas.com wrote:
You run it in Permissive mode, you deal with the exceptions as they arise while the software is running in its normal environment and while its running normally using any of the documented methods. You thoroughly test the application in such a manner and once you have ironed out any and all issues by putting together a custom policy, setting the right SElinux booleans, etc, you then enable Enforcing mode. There is really no reason that SElinux should have a negative impact on your application or server if you use Permissive first.You forgot "take on becoming the SELinux integration manager for that project with every single update".
Every single update? Update of what?
SELinux policy updates do not modify any local policy configuration and settings (if you have them set up in a proper way). It works just as John explained above --- run SELinux in permissive mode in usual working environment and see if there are any denials. To begin with, if all other apps on your machine are ok, there shouldn't be any denials. If there are, it is typically either a bug in the app causing the denial, or insecure configuration settings for that app. In both cases it has nothing to do with SELinux and should be addressed elsewhere. SELinux is actually doing you a favor by pointing out security holes in your system. Still, if you decide that you still want to use the buggy and insecure app/onfiguration, you can modify local SELinux settings to allow access. You do it once, and it works. Updating SELinux policy will not change that.
If you are talking about updating a custom app that keeps conflicting with SELinux, then it's the problem with the app itself --- collect all denials and report a bug upstream against that app. No program that works correctly should ever produce any denials. If upstream don't care, you chose a bad app for your system. Especially if it is a production system.
In either case, it doesn't require any serious maintenance time from the sysadmin. Just one afternoon to learn how to use SELinux properly.
HTH, :-) Marko
Marko Vojinovic wrote:
On Sunday 28 November 2010 03:45:54 Nico Kadel-Garcia wrote:
On Sat, Nov 27, 2010 at 9:21 PM, John R. Dennison jrd@gerdesas.com wrote:
You run it in Permissive mode, you deal with the exceptions as they arise while the software is running in its normal environment and while its running normally using any of the documented methods. You thoroughly test the application in such a manner and once you have ironed out any and all issues by putting together a custom policy, setting the right SElinux booleans, etc, you then enable Enforcing mode. There is really no reason that SElinux should have a negative impact on your application or server if you use Permissive first.You forgot "take on becoming the SELinux integration manager for that project with every single update".
Every single update? Update of what?
Marko,
You have completely missed his point. Every update of the application *his company* is writing to run on those CentOS servers. This has nothing to do with RedHat, CentOS, or any other FLOSS package. It is a management problem within his employer's organization. If the managers don't care to require the application be SE compliant, he will never be able to get the developers to deal with those issues. So for him it is already a lost battle.
Bob McConnell N2SPP
On 11/28/2010 8:15 AM, Bob McConnell wrote:
Marko Vojinovic wrote:
On Sunday 28 November 2010 03:45:54 Nico Kadel-Garcia wrote:
On Sat, Nov 27, 2010 at 9:21 PM, John R. Dennisonjrd@gerdesas.com wrote:
You run it in Permissive mode, you deal with the exceptions as they arise while the software is running in its normal environment and while its running normally using any of the documented methods. You thoroughly test the application in such a manner and once you have ironed out any and all issues by putting together a custom policy, setting the right SElinux booleans, etc, you then enable Enforcing mode. There is really no reason that SElinux should have a negative impact on your application or server if you use Permissive first.You forgot "take on becoming the SELinux integration manager for that project with every single update".
Every single update? Update of what?
Marko,
You have completely missed his point. Every update of the application *his company* is writing to run on those CentOS servers. This has nothing to do with RedHat, CentOS, or any other FLOSS package. It is a management problem within his employer's organization. If the managers don't care to require the application be SE compliant, he will never be able to get the developers to deal with those issues. So for him it is already a lost battle.
Bob McConnell N2SPP
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I run a mix of Centos and Debian. If you setup your system correctly you aren't going to get hammered. It's all down to what apps you are running. SeLinux helps but I find it gets in the way. If SeLinux where the panacea it's being billed as here then more distros would have it enabled by default...however the opposite is true. Contrary to the apparent belief on this list it IS possible to properly harden a box without SeLinux.
On Sunday 28 November 2010 13:15:24 Bob McConnell wrote:
Marko Vojinovic wrote:
On Sunday 28 November 2010 03:45:54 Nico Kadel-Garcia wrote:
You forgot "take on becoming the SELinux integration manager for that project with every single update".
Every single update? Update of what?
You have completely missed his point. Every update of the application *his company* is writing to run on those CentOS servers. This has nothing to do with RedHat, CentOS, or any other FLOSS package. It is a management problem within his employer's organization. If the managers don't care to require the application be SE compliant, he will never be able to get the developers to deal with those issues. So for him it is already a lost battle.
Well, in that case he is dealing with a broken/badly coded app, and irresponsible managers and developers. It's a problem, yes, but this isn't a fault of SELinux, and advocating that SELinux is bad because some manager doesn't know about security is completely wrong IMHO. And supporting advice given to people on this list to turn off SELinux because some devs in some company don't do their job right is also completely wrong.
If Nico had to deal with lousy-coded software conflicting with SELinux, it doesn't mean that shutting down SELinux is a good idea for everyone (or anyone) else.
Best, :-) Marko
Marko Vojinovic wrote:
On Sunday 28 November 2010 13:15:24 Bob McConnell wrote:
Marko Vojinovic wrote:
On Sunday 28 November 2010 03:45:54 Nico Kadel-Garcia wrote:
You forgot "take on becoming the SELinux integration manager for that project with every single update".
Every single update? Update of what?
You have completely missed his point. Every update of the application *his company* is writing to run on those CentOS servers. This has nothing to do with RedHat, CentOS, or any other FLOSS package. It is a management problem within his employer's organization. If the managers don't care to require the application be SE compliant, he will never be able to get the developers to deal with those issues. So for him it is already a lost battle.
Well, in that case he is dealing with a broken/badly coded app, and irresponsible managers and developers. It's a problem, yes, but this isn't a fault of SELinux, and advocating that SELinux is bad because some manager doesn't know about security is completely wrong IMHO. And supporting advice given to people on this list to turn off SELinux because some devs in some company don't do their job right is also completely wrong.
Been there, done that. We had the same problems just a few years ago, managers with no concerns about security as long as everything worked. Our project leader was beside himself trying to get even rudimentary validation and sanitization into the code. Then it was decided that we needed to accept credit card transactions on the server. Suddenly the developers had to learn and apply the OWASP guidelines. Next there was PCI training and a flurry of activity to make all of our web based applications conform before the initial audit.
But SE wasn't even discussed, nor was it ever required. It is still not enabled on any of our test or development servers. The only reason we ended up with it on the production servers was our switch from self-hosted to a managed hosting service who enabled it in the normal course of setting up their servers. Maybe we're just lucky, but we have never touched a line of code because of it.
If Nico had to deal with lousy-coded software conflicting with SELinux, it doesn't mean that shutting down SELinux is a good idea for everyone (or anyone) else.
Maybe not, but the risks should be evaluated on a case by case basis. I don't believe it can be considered a panacea either. Even with SE in full protected mode, a simple SQL injection flaw can still expose much of the sensitive data on your server.
Bob McConnell N2SPP
1,000 pardons for aggressively trimming this post, sorry if I have harmed the flow by being selective.
Bob McConnell wrote:
Marko Vojinovic wrote:
Bob McConnell wrote:
Marko Vojinovic wrote:
Nico Kadel-Garcia wrote:
Hypothetical: one admins a vended suite of applications that comprise an ERP. Many layers of management going all the way up to elected Board members, and by implication the public, have spent $millions to acquire, install, and augment it until it runs every aspect of the business. A thousand staff members and 20,000 customers have been trained to use the system. Major components (LDAP, email, database) come from a Fortune 50 company that was assimilated by another Fortune 50 company. Not one piece of the ERP comes in RPM form.
You have completely missed his point. Every update of the application *his company* is writing to run on those CentOS servers. This has nothing to do with RedHat, CentOS, or any other FLOSS package. It is a management problem within his employer's organization. If the managers
In this (hypothetical) situation, managers don't have the right kind of power. They can't dictate policy to major corporations. They could attempt to bring a couple of dozen in-house applications into compliance, but does that make sense when the ERP is not in compliance thus SELinux is not an option?
Well, in that case he is dealing with a broken/badly coded app, and irresponsible managers and developers. It's a problem, yes, but this isn't a
The ERP is (hypothetically of course) badly broken on many levels. So, what can one constructively do? Complain at a Board meeting? Write letters to the newspapers? Start a boycott against the vendors? Open 1,000 service requests with the vendors? Buy the "myERPsucks" domain name? It's a cumbersome, balky problem that AFAICT has no easy answer. Some issues need attention at the governance level, such as IT getting more involved in vendor selection.
given to people on this list to turn off SELinux because some devs in some company don't do their job right is also completely wrong.
Perhaps completely wrong but also thoroughly entrenched, as explained above.
don't believe it can be considered a panacea either. Even with SE in full protected mode, a simple SQL injection flaw can still expose much of the sensitive data on your server.
An example: Crafty Person enters an account # as: 9000' OR true and for the sake of argument, this retrieves 20,000 customer records. Does SELinux "do" anything? I suspect the answer is no. Tends to support the proceeding argument (it's not a panacea).
On Sunday 28 November 2010 19:18:29 cpolish@surewest.net wrote:
Hypothetical: one admins a vended suite of applications that comprise an ERP. Many layers of management going all the way up to elected Board members, and by implication the public, have spent $millions to acquire, install, and augment it until it runs every aspect of the business. A thousand staff members and 20,000 customers have been trained to use the system. Major components (LDAP, email, database) come from a Fortune 50 company that was assimilated by another Fortune 50 company. Not one piece of the ERP comes in RPM form.
[snip]
given to people on this list to turn off SELinux because some devs in some company don't do their job right is also completely wrong.
Perhaps completely wrong but also thoroughly entrenched, as explained above.
The point I was trying to make is just that disabling SELinux should be done only by exception rather than as a rule of thumb when configuring a server. Ditto for suggesting to others to disable it.
Of course I agree that in some circumstances it is impossible or unneeded to run SELinux. One example is what you have described, another would be, say, an offline machine. If the machine is not connected to the Internet at all, disabling SELinux can bring a performance gain. I've seen this on a couple of clusters used for dedicated computations --- every bit of speed is important, while the machine is completely safe against remote intrusion...
But for a generic server running generic services and facing the Internet, SELinux brings another layer of security, and is quite easy to maintain.
don't believe it can be considered a panacea either. Even with SE in full protected mode, a simple SQL injection flaw can still expose much of the sensitive data on your server.
An example: Crafty Person enters an account # as: 9000' OR true and for the sake of argument, this retrieves 20,000 customer records. Does SELinux "do" anything? I suspect the answer is no. Tends to support the proceeding argument (it's not a panacea).
I agree. However, SELinux can prevent privilege escalation if any particular service or user on the system does get compromised. And this kind of damage limitation can be a life-saver when a mission-critical production server gets compromised (for example, by some user having a weak password, as happened to me on several occasions).
So it is better to have SELinux running then not, unless you are absolutely forced to turn it off. And even then, there is permissive mode, which can be quite useful sometimes.
Best, :-) Marko
On Sun, Nov 28, 2010 at 10:39 AM, Bob McConnell rmcconne@lightlink.com wrote:
Marko Vojinovic wrote:
On Sunday 28 November 2010 13:15:24 Bob McConnell wrote:
Marko Vojinovic wrote:
On Sunday 28 November 2010 03:45:54 Nico Kadel-Garcia wrote:
You forgot "take on becoming the SELinux integration manager for that project with every single update".
Every single update? Update of what?
You have completely missed his point. Every update of the application *his company* is writing to run on those CentOS servers. This has nothing to do with RedHat, CentOS, or any other FLOSS package. It is a management problem within his employer's organization. If the managers don't care to require the application be SE compliant, he will never be able to get the developers to deal with those issues. So for him it is already a lost battle.
His companies. Plural.
I've been in way too many envornments where various applicatons have ben brought in, from outside sources, with wildly disparate security models. It's gotten better, as SELinux itself has matured and code that's complete crap is less likely to be deployed. This is often because, I, pesonally, take a look at code coming from people who have *no idea* how badly their tools violate basic security principals and UNIX file system behaviors and help them clean it up. In fact, I can give you an example.
Allow you to give a specific sample. The "lilac" tool for Nagios configuration allows powerful manipulation, including the insertion of shell scripting, for Nagios and NRPE configurations. So good do far, right? It's in PHP, and run as the 'apache' user, and needs ot be able to restart that daimon. So the "apache" user needs root privileges to restart a daemon, because the "/var/run" information for the relevant daomon is in /var/un/. It can't easily be Apache suexec operated because it's based on a full PHP web based site, not a CGI program, and the default sudo won't work because there's no tty associated with PhP operations.
Now, insert SELinux privilege management into the mix, and watch your brain explode as you try to track the issues. (I did. It was very messy). And update your SELinux setup *eveyr time* you update the core software, unsupported by the author who doens't play that game.
Well, in that case he is dealing with a broken/badly coded app, and irresponsible managers and developers. It's a problem, yes, but this isn't a
I'm dealing with the software as it's published. I'm afraid a tremendous amount of software is written *terribly* in security terms. Take a look at jabber and subversion, storing passwords in plaintext, for examples.
fault of SELinux, and advocating that SELinux is bad because some manager doesn't know about security is completely wrong IMHO. And supporting advice given to people on this list to turn off SELinux because some devs in some company don't do their job right is also completely wrong.
No, I quesiton its utility because the engineering effort is burdensome, it wastes testing cycles best spent elsewhere, and the error messages are.... less than helpful.
Been there, done that. We had the same problems just a few years ago, managers with no concerns about security as long as everything worked. Our project leader was beside himself trying to get even rudimentary validation and sanitization into the code. Then it was decided that we needed to accept credit card transactions on the server. Suddenly the developers had to learn and apply the OWASP guidelines. Next there was PCI training and a flurry of activity to make all of our web based applications conform before the initial audit.
But SE wasn't even discussed, nor was it ever required. It is still not enabled on any of our test or development servers. The only reason we ended up with it on the production servers was our switch from self-hosted to a managed hosting service who enabled it in the normal course of setting up their servers. Maybe we're just lucky, but we have never touched a line of code because of it.
If Nico had to deal with lousy-coded software conflicting with SELinux, it doesn't mean that shutting down SELinux is a good idea for everyone (or anyone) else.
Maybe not, but the risks should be evaluated on a case by case basis. I don't believe it can be considered a panacea either. Even with SE in full protected mode, a simple SQL injection flaw can still expose much of the sensitive data on your server.
Amen. I have this issue with Subversion. I don't *CARE* if you use HTTPS, when the passwords are stored in clear text on the client and optionally in clear text on the server.
On 11/28/2010 7:55 PM, Nico Kadel-Garcia wrote:
On Sun, Nov 28, 2010 at 10:39 AM, Bob McConnellrmcconne@lightlink.com wrote:
Marko Vojinovic wrote:
On Sunday 28 November 2010 13:15:24 Bob McConnell wrote:
Marko Vojinovic wrote:
On Sunday 28 November 2010 03:45:54 Nico Kadel-Garcia wrote:
You forgot "take on becoming the SELinux integration manager for that project with every single update".
Every single update? Update of what?
You have completely missed his point. Every update of the application *his company* is writing to run on those CentOS servers. This has nothing to do with RedHat, CentOS, or any other FLOSS package. It is a management problem within his employer's organization. If the managers don't care to require the application be SE compliant, he will never be able to get the developers to deal with those issues. So for him it is already a lost battle.
His companies. Plural.
I've been in way too many envornments where various applicatons have ben brought in, from outside sources, with wildly disparate security models. It's gotten better, as SELinux itself has matured and code that's complete crap is less likely to be deployed. This is often because, I, pesonally, take a look at code coming from people who have *no idea* how badly their tools violate basic security principals and UNIX file system behaviors and help them clean it up. In fact, I can give you an example.
Allow you to give a specific sample. The "lilac" tool for Nagios configuration allows powerful manipulation, including the insertion of shell scripting, for Nagios and NRPE configurations. So good do far, right? It's in PHP, and run as the 'apache' user, and needs ot be able to restart that daimon. So the "apache" user needs root privileges to restart a daemon, because the "/var/run" information for the relevant daomon is in /var/un/. It can't easily be Apache suexec operated because it's based on a full PHP web based site, not a CGI program, and the default sudo won't work because there's no tty associated with PhP operations.
Now, insert SELinux privilege management into the mix, and watch your brain explode as you try to track the issues. (I did. It was very messy). And update your SELinux setup *eveyr time* you update the core software, unsupported by the author who doens't play that game.
Well, in that case he is dealing with a broken/badly coded app, and irresponsible managers and developers. It's a problem, yes, but this isn't a
I'm dealing with the software as it's published. I'm afraid a tremendous amount of software is written *terribly* in security terms. Take a look at jabber and subversion, storing passwords in plaintext, for examples.
fault of SELinux, and advocating that SELinux is bad because some manager doesn't know about security is completely wrong IMHO. And supporting advice given to people on this list to turn off SELinux because some devs in some company don't do their job right is also completely wrong.
No, I quesiton its utility because the engineering effort is burdensome, it wastes testing cycles best spent elsewhere, and the error messages are.... less than helpful.
Been there, done that. We had the same problems just a few years ago, managers with no concerns about security as long as everything worked. Our project leader was beside himself trying to get even rudimentary validation and sanitization into the code. Then it was decided that we needed to accept credit card transactions on the server. Suddenly the developers had to learn and apply the OWASP guidelines. Next there was PCI training and a flurry of activity to make all of our web based applications conform before the initial audit. But SE wasn't even discussed, nor was it ever required. It is still not enabled on any of our test or development servers. The only reason we ended up with it on the production servers was our switch from self-hosted to a managed hosting service who enabled it in the normal course of setting up their servers. Maybe we're just lucky, but we have never touched a line of code because of it.
If Nico had to deal with lousy-coded software conflicting with SELinux, it doesn't mean that shutting down SELinux is a good idea for everyone (or anyone) else.
Maybe not, but the risks should be evaluated on a case by case basis. I don't believe it can be considered a panacea either. Even with SE in full protected mode, a simple SQL injection flaw can still expose much of the sensitive data on your server.
Amen. I have this issue with Subversion. I don't *CARE* if you use HTTPS, when the passwords are stored in clear text on the client and optionally in clear text on the server. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
run the php code inside of a cgi wrapper as the user not apache.
On Monday 29 November 2010 00:55:47 Nico Kadel-Garcia wrote:
On Sun, Nov 28, 2010 at 10:39 AM, Bob McConnell rmcconne@lightlink.com
wrote:
fault of SELinux, and advocating that SELinux is bad because some manager doesn't know about security is completely wrong IMHO. And supporting advice given to people on this list to turn off SELinux because some devs in some company don't do their job right is also completely wrong.
No, I quesiton its utility because the engineering effort is burdensome, it wastes testing cycles best spent elsewhere, and the error messages are.... less than helpful.
Just a small suggestion regarding the error messages --- take a look at setroubleshoot, it was designed to help out with making AVC denials more human-friendly. And it typically works quite well.
When triggered by a denial, setroubleshoot alerts the user, explains what went wrong, why it went wrong and what options you have for fixing it. All that in nice plain english :-). Typically it also tells you the exact set of commands you need to execute if you wish to modify the policy to allow that particular access. If you are aware of the risks and know what you are doing, a couple of copy&paste commands in the root prompt removes the SELinux restrictions for good. It also works in permissive mode, if you wish to tweak your local policy without impacting a runtime environment.
Of course, it is not always a good idea to modify the policy (it would be better to remove the problem at app/config level), but sometimes one doesn't have a choice, as in your case. :-)
HTH, :-) Marko
On Sunday, November 28, 2010 10:39:22 am Bob McConnell wrote:
Maybe not, but the risks should be evaluated on a case by case basis. I don't believe it can be considered a panacea either. Even with SE in full protected mode, a simple SQL injection flaw can still expose much of the sensitive data on your server.
That's when something like SEPostgreSQL can help. Yeah, SELinux controls in the database itself. See http://wiki.postgresql.org/wiki/SEPostgreSQL for more information.
If you have sensitive data, you need to be diligent. The people behind SELinux are the country's leading experts on information sensitivity and compartmentalization.
Yeah, that sort of control can be a pain, but if the data is truly sensitive you simply must take pains with it.
SELinux on the desktop is a great thing, too, especially if you want to thwart drive-by web bugs and such (you set your controls to not allow Firefox access but to specific areas of your home directory, and you set certain areas of your home directory off limits except to certain programs: you're worm-proof then, and, if you're careful, data-theft-proof). But that fine-grained control means you have to maintain those controls, and require due diligence.
It is and has always been a balance between convenience and security; truly tight security, which SELinux can give you in droves, is a time-consuming and not very convenient affair.
But if you think you're fully locked down without controls similar to SELinux, you are simply wrong, and an attacker will prove that to you one day. Firewalls are not enough by themselves. SELinux is likely not enough by itself; layers do the trick, so that when an exploit in one layer occurs the other layer catches it (and hopefully you find out about it).
Intrusion detection is good, but, once an intrusion is detected it might be too late, depending upon the intrusion. And intrusion 'signatures' (much like virus signatures) are no good at all against previously undetected threats. SELinux allows you (especially with permissive mode) to see the access footprint of an application, and tailor the security to the normal access footprint. Allow only what is normal, and it's much harder (not impossible) to exploit things.
No security is perfect; multiple layers of diverse security on multiple platforms helps immensely.
On 11/27/2010 09:21 PM, John R. Dennison wrote:
On Sat, Nov 27, 2010 at 08:23:34PM -0500, Nico Kadel-Garcia wrote:
The "working system" in that analogy is software, not necessarily nor even likely to be the kernel itself. But yes, it can trash a production critical web or software application that didn't follow the sensible, but often poorly understood, policies of SELinux. This is particularly common with 3rd party web applications, the sort of thing we grab from Sourceforge and try ourselves. (Lilac, the Nagios configuration tool, particularly comes to mind.)
I'd have to dig back to rediscover the Lilac issues, but I remember running out of time to sort them all out and having to leave SELinux off of that server.
heh, fail.
You run it in Permissive mode, you deal with the exceptions as they arise while the software is running in its normal environment and while its running normally using any of the documented methods. You thoroughly test the application in such a manner and once you have ironed out any and all issues by putting together a custom policy, setting the right SElinux booleans, etc, you then enable Enforcing mode. There is really no reason that SElinux should have a negative impact on your application or server if you use Permissive first.
John
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I don't know how it is now - but I tried running in permissive mode a few years ago. It would complain about some file, I would fix the file and the next thing I knew it was complaining about the same file again, and the file was part of the redhat installation. After that I gave up and just turned it off.
On Monday, November 29, 2010 08:11 PM, Steve Clark wrote:
I don't know how it is now - but I tried running in permissive mode a few years ago. It would complain about some file, I would fix the file and the next thing I knew it was complaining about the same file again, and the file was part of the redhat installation. After that I gave up and just turned it off.
I never tried it on Centos 4 but when I had to implement it on Centos 5 in September this year, I did not encounter what you experienced.
It could be simply because I took pains to ensure the system knew how to relabel stuff beyond the defaults that it was programmed to do. I cannot remember if I had to make a rule for something that is installed by anaconda but I do believe that if you have change anything from the defaults, you need to teach the relabel system. Like Marko posted: man semanage.
On 29/11/10 13:11, Steve Clark wrote:
I don't know how it is now - but I tried running in permissive mode a few years ago. It would complain about some file, I would fix the file and the next thing I knew it was complaining about the same file again, and the file was part of the redhat installation. After that I gave up and just turned it off.
If you use chcon to change the security context of a file, then it will be restored to the "wrong" security context on the next relabelling.
If you rather use 'semanage fcontext' you can permanently set the security context for files. Then you can run restorecon or relabel your filesystem, and it should be set with the proper security context. Running semanage alone will not change the security context, but running restorecon afterwards will do that.
Another way to do it, is to write a security module and load that security module with semodule. But that's a heavier path to take, especially if 'semanage fcontext' can do the job for you.
kind regards,
David Sommerseth
On 11/27/2010 02:52 PM, Marko Vojinovic wrote:
On Saturday 27 November 2010 18:57:50 Benjamin Franz wrote:
On 11/26/2010 05:17 PM, Patrick Lists wrote:
What's with people recommending to turn off SELinux?! That's just bad advice and like recommending people keep their doors unlocked at all times. Really, stop doing that. SELinux is there for a reason.
SELinux is like a automatic collision avoidance system for an airplane that unpredictably crashes the plane during normal flight. While the basic idea is good, until it stops crashing planes without warning it isn't going to be accepted.
I don't understand this analogy. I have never seen SELinux crashing the system or doing some damage otherwise. What experience do you have with SELinux crashing anything on a working system?
My experience with SELinux updates are that you can't predict. It could be filling up your disk with logs it forgot to delete after rotateing . It could be breaking X, disabling a previously working Apache configuration, breaking previously working mail systems, and so on.
It is not enough that it mitigates certain classes of attacks when it actively breaks running systems *more often* than it mitigates attacks. And that is my personal experience. Every year or two I try turning it on on a few systems. And then, after it suddenly decides to break a previously stable system - it gets turned back off.
If your system was running for some time with SELinux disabled (not in permissive mode, but disabled), turning it on without doing a proper relabeling of the filesystem is known to be a very Bad Idea. Typically all problems that occur in this situation can be eliminated by relabeling the whole filesystem once. Maybe that was the step you missed?
No. I didn't phrase it clearly enough. I build systems fairly frequently. And periodically I'll decide that one of them will have SELinux turned on right from the start. And after I spend the time to make everything happy, it will work. The system will be stable. For a while.
And then, one day, it won't work. Worse - it doesn't always *log* what it is doing in a way that you can figure out. Occasionally not at all. So you spend a few hours poking at the system until you try the magic of turning off SELinux. And then it starts working again.
My experience is that *unless you have a system configured exactly like the defaults*, SELinux is prone to suddenly deciding after an update that it doesn't like your configuration anymore. Once because an update to SELinux changed the labeling on an existing directory tree - blowing away my own applied labeling with no warning. And there are even RH supplied rpms that *do not work* with SELinux without being SELinux being tweaked first.
I've had one machine (of several dozen running) hacked in 15 years (entirely because I forgot to keep it updated). It was several years ago.
I've had several instances of SELinux breaking a previously stable system after an update to SELinux or its policies. On about the same number of machines. The most recent within the last year.
I've been burned by SELinux's misbehavior multiple times. It will take a very long time for it to earn my trust again.
On Sunday 28 November 2010 13:31:28 Benjamin Franz wrote:
Worse - it doesn't always log what it is doing in a way that you can figure out. Occasionally not at all.
SELinux does have some rate-limiting capabilities built-in to avoid a flood of identical messages...so the "triggering-event to log ratio" is not 1 to 1. I understand this may be confusing for troubleshooting purposes but you need to be aware of this.
Once because an update to SELinux changed the labeling on an existing directory tree - blowing away my own applied labeling with no warning
When you apply custom labels to files many people forget that if there's a relabel involved (via /.autorelabel or manual filesystem relabel) all your custom labels are gone UNLESS you update your local policy contexts by doing:
semanage fcontext -a -t new_type_here 'regex_here'
I've had several instances of SELinux breaking a previously stable system after an update to SELinux or its policies. On about the same number of machines. The most recent within the last year.
All our CentOS 5 servers have been running smooth with SELinux enabled. I can't tell from previous versions since I always disabled it (I was intimidated by it until I decided to take SOME TIME to read about it and UNDERSTAND it). Once you grasp the essentials isn't that of a big issue really.
If you are running the packages that come with your distro and you leave the stuff in their respective places (/var/www/html etc), you shouldn't be doing much tweaking.
In a nutshell, for me, when I suspect there is something related to SELinux involved I proceed as follows:
1) I'll check the logs to see if there's any AVC message. If there is...
2) I'll check if this is related to a mislabeled file. If it is, I'll fix the label. If the file in question is on a standard place...a simple restorecon should work but if the file is in another place (non-standard location) I'll need to register that as a local customization to the file contexts (with semanage fcontext...)
3) If the label is correct for the file I'll check if there's a boolean to control (allow/deny) this action (example: there are booleans to allow ftp server to serve from home directories or not etc...)
4) If there is no boolean and I'm 100% the access is needed...I'll create a local custom-policy with audit2allow.
That's basically it.
On the other hand, there are situations like, for example, our RHEL servers running Oracle databases. There's no way to run SELinux as Oracle won't support it. I heard they're working on it and in future versions they might support it (or maybe their current one I'm not sure). In other cases where we use Symantec Netbackup (the client installed on all servers) we just needed to change some labels on some specific libraries and that was all. Luckily this was well documented and there were some KB articles about this.
There has been a lot of progress with SELinux lately. I think you should reconsider your position and perhaps give it a try on the upcoming CentOS 6 where the targeted policy is much matured.
Best regards, Jorge
On 11/28/10 1:06 PM, Jorge Fábregas wrote:
There has been a lot of progress with SELinux lately. I think you should reconsider your position and perhaps give it a try on the upcoming CentOS 6 where the targeted policy is much matured.
SELinux has been around many years now. Are there any objective metrics we can observe instead of having people rant about their own opinions here?
Things like: Number of bugs posted against SELinux itself. Measured hours of effort to learn the system well. Ratio of security breeches expected on systems that do/don't include SELinux. Lists of 3rd party apps that do/don't work with SELinux.
Without those, it's all handwaving and if there aren't any real metrics it's fair to assume the value isn't worth the trouble you can expect.
On Sunday 28 November 2010 19:28:17 Les Mikesell wrote:
On 11/28/10 1:06 PM, Jorge Fábregas wrote:
There has been a lot of progress with SELinux lately. I think you should reconsider your position and perhaps give it a try on the upcoming CentOS 6 where the targeted policy is much matured.
SELinux has been around many years now. Are there any objective metrics we can observe instead of having people rant about their own opinions here?
Things like: Number of bugs posted against SELinux itself.
If you mean actual SELinux code (built in the kernel), it's a reasonably simple thing, AFAIK. In a nutshell, it takes the label of the app trying to gain some access, the label of the file being accessed, and looks up in a table of rules (the policy) to see if the two are compatible. It isn't much different than the permissions system or the firewall. I don't expect any serious number of bugs reported against the code that implements that kind of thing.
If, however, you mean the SELinux policy, this is a moving target --- it evolves and changes even without bug reports, so any potential number of reported bugs would not be much useful as a meaningful piece of metric.
Measured hours of effort to learn the system well.
man chcon man restorecon man semanage
That gives you all operational knowledge one typically needs when dealing with SELinux. Of course, you can always invest more time and read a more elaborate piece of documentation, if you wish.
But for a reasonably capable sysadmin, reading three man pages is not a terrible effort, it can be done in less than one hour.
Ratio of security breeches expected on systems that do/don't includeSELinux. Lists of 3rd party apps that do/don't work with SELinux.
I wouldn't know the typical ratio itself as a number, but I can tell you it is surely less than one. I had three identical systems compromised at the same time (one of the users had a weak password, and he used the same password on all three machines... you wouldn't believe...). Two systems had SELinux disabled, the third one had it enabled. For the first two, intruder managed to escalate to root and I had a busy weekend reinstalling those machines from scratch afterwards. For the third one, the intruder never managed to escalate to root, and this was clearly visible in SELinux and other system logs. I simply purged that user account and had everything working in no time.
So in essence, there is at least one machine (that I know of first-hand) where SELinux prevented a serious intrusion. Therefore, the do/don't ratio of breaches is surely less than one. :-)
Without those, it's all handwaving and if there aren't any real metrics it's fair to assume the value isn't worth the trouble you can expect.
If there aren't any real metrics, it's only safe not to assume anything. The pain/gain ratio can only be estimated for each particular case separately. If it doesn't give you too much pain, SELinux is certainly a good thing to have around, in enforcing mode. :-)
Best, :-) Marko
On 11/28/10 5:29 PM, Marko Vojinovic wrote:
I wouldn't know the typical ratio itself as a number, but I can tell you it is surely less than one. I had three identical systems compromised at the same time (one of the users had a weak password, and he used the same password on all three machines... you wouldn't believe...). Two systems had SELinux disabled, the third one had it enabled. For the first two, intruder managed to escalate to root and I had a busy weekend reinstalling those machines from scratch afterwards. For the third one, the intruder never managed to escalate to root, and this was clearly visible in SELinux and other system logs. I simply purged that user account and had everything working in no time.
But that means you were running software with vulnerabilities or a user would not be able to become root anyway. Is that due to not being up to date (i.e. would normal, non-SELinux measures have been enough), or was this before a fix was available?
On Monday 29 November 2010 03:37:29 Les Mikesell wrote:
On 11/28/10 5:29 PM, Marko Vojinovic wrote:
I wouldn't know the typical ratio itself as a number, but I can tell you it is surely less than one. I had three identical systems compromised at the same time (one of the users had a weak password, and he used the same password on all three machines... you wouldn't believe...). Two systems had SELinux disabled, the third one had it enabled. For the first two, intruder managed to escalate to root and I had a busy weekend reinstalling those machines from scratch afterwards. For the third one, the intruder never managed to escalate to root, and this was clearly visible in SELinux and other system logs. I simply purged that user account and had everything working in no time.
But that means you were running software with vulnerabilities or a user would not be able to become root anyway. Is that due to not being up to date (i.e. would normal, non-SELinux measures have been enough), or was this before a fix was available?
Well, the kernel I used at the time had a known exploit (exploitable by some services I was running), and the intruder got advantage of that. Of course, it was partly my fault, because I didn't restart those machines for a long time, so the updated kernel wasn't running on them.
True, if I kept the kernel up-to-date, he wouldn't be able to gain root on any of the machines. But given that I am administrating these machines remotely (from a different country, several thousand km away), I don't quite enjoy rebooting them just to activate the latest kernel. If something goes wrong and the machine fails to boot, I need someone local to help me out, have a lot of downtime, etc.
So yes, I agree, if I took good care of the rest of the system nothing serious would have happened. But in this particular case SELinux saved my skin, since the third machine could take the load from the first two while these were kickstarted by a friend of mine... :-)
Best, :-) Marko
On Monday, November 29, 2010 08:50 PM, Marko Vojinovic wrote:
Well, the kernel I used at the time had a known exploit (exploitable by some services I was running), and the intruder got advantage of that. Of course, it was partly my fault, because I didn't restart those machines for a long time, so the updated kernel wasn't running on them.
So yes, I agree, if I took good care of the rest of the system nothing serious would have happened. But in this particular case SELinux saved my skin, since the third machine could take the load from the first two while these were kickstarted by a friend of mine... :-)
There is also the case of recently discovered exploits. Like the one in phpmysqladmin that was made known in September. Okay, the HQ chap was inept in allowing anybody to access phpmysqladmin imagining that the password protection was sufficient and at the same time allowing access to setup.php from anyone on the Net so he could have prevented it the whole thing in the first place without the protection of SELinux. But had he had SELinux running, it could have foiled the upload of the bot and subsequent execution.
On Sunday, November 28, 2010 10:37:29 pm Les Mikesell wrote:
But that means you were running software with vulnerabilities or a user would not be able to become root anyway. Is that due to not being up to date (i.e. would normal, non-SELinux measures have been enough), or was this before a fix was available?
By definition we are all running software with vulnerabilities. Those vulnerabilities may not be public knowledge yet, but they are there, and many are likely known by the blackhats already, and kept 'mum.'
Fixing vulnerabilities and keeping up to date alone is insufficient to keep you secure. Can you say 'zero day?'
SELinux is a powerful tool in helping combat zero day exploits from succeeding, in many cases.
Can it be a pain? Sure it can. It has improved greatly, in my experience, thanks in no small part to the dedicated Fedora team working on selinux packages. This inlcudes the upstream developers, the Fedora packagers, the QA team, and ESPECIALLY the Fedora users who take time to file informative and useful reports while using the system with SELinux in enforcing mode. No pain, no gain.
I've run with SELinux in enforcing (targeted) mode on my laptop, now, since Fedora 11, and have only had two issues that required some head-scratching. One was solved by a relabel. The other was a little more devious, but a little tweaking which in permissive mode showed me the solution. I did learn a couple of really good lessons from that, though. The first was to always keep a Fedora Live boot media with the laptop (CD or USB, or another partition on the hard disk). The second was that there are some updates that must occur in pairs, and occasionally a relabel of at least part of the filesystem is going to be required. But that's not hard to trigger, and isn't that inconvenient.
On 11/29/2010 10:17 AM, Lamar Owen wrote:
On Sunday, November 28, 2010 10:37:29 pm Les Mikesell wrote:
But that means you were running software with vulnerabilities or a user would not be able to become root anyway. Is that due to not being up to date (i.e. would normal, non-SELinux measures have been enough), or was this before a fix was available?
By definition we are all running software with vulnerabilities. Those vulnerabilities may not be public knowledge yet, but they are there, and many are likely known by the blackhats already, and kept 'mum.'
Fixing vulnerabilities and keeping up to date alone is insufficient to keep you secure. Can you say 'zero day?'
Agreed, but not everyone has time to do both - or to learn lots of distribution-specific details in mixed environments. My opinion is that doing the simple stuff first is a win. And that works the same on systems that don't include SELinux.
SELinux is a powerful tool in helping combat zero day exploits from succeeding, in many cases.
And it also keeps most 3rd party software from working. If you are storing credit card numbers or personal information that would be expensive to leak, then you obviously need to make every effort possible to block intrusion, although the people who regulate this stuff don't require SELinux explicitly. But not all machines do that.
I've run with SELinux in enforcing (targeted) mode on my laptop, now, since Fedora 11, and have only had two issues that required some head-scratching. One was solved by a relabel. The other was a little more devious, but a little tweaking which in permissive mode showed me the solution. I did learn a couple of really good lessons from that, though. The first was to always keep a Fedora Live boot media with the laptop (CD or USB, or another partition on the hard disk). The second was that there are some updates that must occur in pairs, and occasionally a relabel of at least part of the filesystem is going to be required. But that's not hard to trigger, and isn't that inconvenient.
How much 3rd party software do you run where someone else has not already spent the time to work out the policies needed to let it work?
Les Mikesell wrote:
On 11/29/2010 10:17 AM, Lamar Owen wrote:
On Sunday, November 28, 2010 10:37:29 pm Les Mikesell wrote:
<snip>
How much 3rd party software do you run where someone else has not already spent the time to work out the policies needed to let it work?
And how much in-house developed software do you run? Or, about those 3rd party software, do you run my own personal PITA, CA's $$$ SiteMinder?
mark
On 11/29/2010 10:46 AM, m.roth@5-cent.us wrote:
How much 3rd party software do you run where someone else has not already spent the time to work out the policies needed to let it work?
And how much in-house developed software do you run? Or, about those 3rd party software, do you run my own personal PITA, CA's $$$ SiteMinder?
In-house software with 3rd party components and stuff running under Java is the main reason for most of our machines. I'm not sure we'd have any that just use the base distro packages. Some stuff uses SUSE because the developer claims their realtime kernel is required for performance. Letting SELinux break other things would be turned into an argument to move them to SUSE.
On Monday, November 29, 2010 11:29:31 am Les Mikesell wrote:
Agreed, but not everyone has time to do both - or to learn lots of distribution-specific details in mixed environments. My opinion is that doing the simple stuff first is a win. And that works the same on systems that don't include SELinux.
The simple stuff on the Fedora box with SELinux is using the targeted policy in enforcing mode. Updates are easy, but there is always a lag from vulnerability discovery to vulnerability patching.
Security isn't simple. The mantra 'just disable SELinux, you don't need it anyway because it's too big of a pain and apps that aren't part of the tested distribution can break' is oversimplifying a complex issue. My opinion is that I'm not going to run third party apps that break in that way, and I'm going to let the developers know why.
SELinux is a powerful tool in helping combat zero day exploits from succeeding, in many cases.
And it also keeps most 3rd party software from working.
I'd ask you to qualify most. All of the third-party software I run seems to run just fine, as long as the right contexts are applied. The most difficult was Scalix, but that wasn't too difficult, since the culprit (the embedded PostgreSQL server running on a nonstandard port with a nonstandard file tree) had a fairly simple policy change to be done, thanks to permissive mode.
If you are storing credit card numbers or personal information that would be expensive to leak, then you obviously need to make every effort possible to block intrusion, although the people who regulate this stuff don't require SELinux explicitly. But not all machines do that.
If I use my laptop to do my online banking, then my browser cache, cookies, and other browser-stored data become critical. Client-side data in this case, but no less critical.
I've run with SELinux in enforcing (targeted) mode on my laptop, now, since Fedora 11, and have only had two issues that required some head-scratching.
How much 3rd party software do you run where someone else has not already spent the time to work out the policies needed to let it work?
A few things, and none were very hard to set up. On the server side Scalix was the most difficult, but still not hard.
On 11/29/2010 10:52 AM, Lamar Owen wrote:
On Monday, November 29, 2010 11:29:31 am Les Mikesell wrote:
Agreed, but not everyone has time to do both - or to learn lots of distribution-specific details in mixed environments. My opinion is that doing the simple stuff first is a win. And that works the same on systems that don't include SELinux.
The simple stuff on the Fedora box with SELinux is using the targeted policy in enforcing mode. Updates are easy, but there is always a lag from vulnerability discovery to vulnerability patching.
Security isn't simple. The mantra 'just disable SELinux, you don't need it anyway because it's too big of a pain and apps that aren't part of the tested distribution can break' is oversimplifying a complex issue. My opinion is that I'm not going to run third party apps that break in that way, and I'm going to let the developers know why.
The user/group/other unix permission set is simple and it works unless something is broken. If you can't get that right you have no hope of doing better with anything else. More complex systems existed before unix and the argument that simplifying the setup to something understandable was a win was correct then and still is. The concept of adding layers is OK, but not if you don't get the simple version right first and make an effort not to run broken software.
SELinux is a powerful tool in helping combat zero day exploits from succeeding, in many cases.
And it also keeps most 3rd party software from working.
I'd ask you to qualify most.
Pretty much anything that needs to write files outside of the home directory of the owning user. Certainly anything that uses apache with its own data store.
All of the third-party software I run seems to run just fine, as long as the right contexts are applied.
Well, obviously it will work after someone takes the time to make it work. Now it is your turn to quantify: How much would you charge to teach someone to be able to make those changes and how long would it take? This has to include the ability to quickly diagnose and fix any problem that might be caused by updates to the application or to the OS distribution.
On Tuesday, November 30, 2010 01:38 AM, Les Mikesell wrote:
All of the third-party software I run seems to run just fine, as long as the right contexts are applied.
Well, obviously it will work after someone takes the time to make it work. Now it is your turn to quantify: How much would you charge to teach someone to be able to make those changes and how long would it take? This has to include the ability to quickly diagnose and fix any problem that might be caused by updates to the application or to the OS distribution.
As was already mentioned in another post, run in permissive mode, for a few days if you must, and go through all the things the software does and voila! setroubleshoot and/or logs tell you what needs doing.
You can switch from enforcing mode to permissive mode in real time, no reboot necessary. All this yapping about the time and effort needed is an excuse when it is TRIVIAL to switch modes and as has already been pointed out, setroubleshoot will explain everything and even tell you exactly in most cases what commands need running to fix things.
Christopher Chan wrote:
Les Mikesell wrote:
All of the third-party software I run seems to run just fine, as long as the right contexts are applied.
Well, obviously it will work after someone takes the time to make it work. Now it is your turn to quantify: How much would you charge to teach someone to be able to make those changes and how long would it take? This has to include the ability to quickly diagnose and fix any problem that might be caused by updates to the application or to the OS distribution.
As was already mentioned in another post, run in permissive mode, for a few days if you must, and go through all the things the software does and voila! setroubleshoot and/or logs tell you what needs doing.
Very optimistic, that. In my shop, some things run annually. A comprehensive system test = production, for a year. Just this morning a 1099 (annual tax-form) script failed in test.
----- Original Message ----- From: cpolish@surewest.net
Christopher Chan wrote:
Les Mikesell wrote:
All of the third-party software I run seems to run just fine, as long as the right contexts are applied.
Well, obviously it will work after someone takes the time to make it work. Now it is your turn to quantify: How much would you charge to teach someone to be able to make those changes and how long would it take? This has to include the ability to quickly diagnose and fix any problem that might be caused by updates to the application or to the OS distribution.
As was already mentioned in another post, run in permissive mode, for a few days if you must, and go through all the things the software does and voila! setroubleshoot and/or logs tell you what needs doing.
Very optimistic, that. In my shop, some things run annually. A comprehensive system test = production, for a year. Just this morning a 1099 (annual tax-form) script failed in test.
For some reason, I suspect that these annual stuff would be largely run by hand. Of course, it would be nice if you don't have to get a call for these annual stuff but I do not see that as absolutely so disabling that SELinux has to be disabled.
On 30/11/10 03:52, cpolish@surewest.net wrote:
Christopher Chan wrote:
Les Mikesell wrote:
[...snip...]
As was already mentioned in another post, run in permissive mode, for a few days if you must, and go through all the things the software does and voila! setroubleshoot and/or logs tell you what needs doing.
Very optimistic, that. In my shop, some things run annually. A comprehensive system test = production, for a year. Just this morning a 1099 (annual tax-form) script failed in test.
So you would rather disable SELinux completely - 365 days a year, rather than to switch to permissive mode when running this script once a year?
I'm sorry, but I'm not able follow that logic.
In fact after running successfully in permissive mode once, you should be able to figure out what your script does, use audit2allow and get a proper SELinux module for it ready in the matter of minutes or hours (depending on how invasive the script is).
kind regards,
David Sommerseth
On 12/8/10 4:22 AM, David Sommerseth wrote:
On 30/11/10 03:52, cpolish@surewest.net wrote:
Christopher Chan wrote:
Les Mikesell wrote:
[...snip...]
As was already mentioned in another post, run in permissive mode, for a few days if you must, and go through all the things the software does and voila! setroubleshoot and/or logs tell you what needs doing.
Very optimistic, that. In my shop, some things run annually. A comprehensive system test = production, for a year. Just this morning a 1099 (annual tax-form) script failed in test.
So you would rather disable SELinux completely - 365 days a year, rather than to switch to permissive mode when running this script once a year?
I'm sorry, but I'm not able follow that logic.
In our case if something fails once a year we lose customers and money. I'd expect that to be fairly common.
On Wednesday, December 08, 2010 09:31 PM, Les Mikesell wrote:
On 12/8/10 4:22 AM, David Sommerseth wrote:
On 30/11/10 03:52, cpolish@surewest.net wrote:
Christopher Chan wrote:
Les Mikesell wrote:
[...snip...]
As was already mentioned in another post, run in permissive mode, for a few days if you must, and go through all the things the software does and voila! setroubleshoot and/or logs tell you what needs doing.
Very optimistic, that. In my shop, some things run annually. A comprehensive system test = production, for a year. Just this morning a 1099 (annual tax-form) script failed in test.
So you would rather disable SELinux completely - 365 days a year, rather than to switch to permissive mode when running this script once a year?
I'm sorry, but I'm not able follow that logic.
In our case if something fails once a year we lose customers and money. I'd expect that to be fairly common.
Again, that particular process is unlikely to be missed and also show to be easily mitigated by doing a realtime switch from enforcing to permissive. Such annual processes are fairly common and usually run manually. You have yet to make a compelling case for completely disabling SELinux just for this sort of thing.
On 12/8/2010 9:13 AM, Christopher Chan wrote:
On Wednesday, December 08, 2010 09:31 PM, Les Mikesell wrote:
On 12/8/10 4:22 AM, David Sommerseth wrote:
On 30/11/10 03:52, cpolish@surewest.net wrote:
Christopher Chan wrote:
Les Mikesell wrote:
[...snip...]
As was already mentioned in another post, run in permissive mode, for a few days if you must, and go through all the things the software does and voila! setroubleshoot and/or logs tell you what needs doing.
Very optimistic, that. In my shop, some things run annually. A comprehensive system test = production, for a year. Just this morning a 1099 (annual tax-form) script failed in test.
So you would rather disable SELinux completely - 365 days a year, rather than to switch to permissive mode when running this script once a year?
I'm sorry, but I'm not able follow that logic.
In our case if something fails once a year we lose customers and money. I'd expect that to be fairly common.
Again, that particular process is unlikely to be missed and also show to be easily mitigated by doing a realtime switch from enforcing to permissive. Such annual processes are fairly common and usually run manually. You have yet to make a compelling case for completely disabling SELinux just for this sort of thing. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
loosing customers and money on an annual basis is a great reason to kill it. Make it able to work without updates interfering with a formerly running configuration on a regular basis and more folks will adopt it. Saying killing it because it is hurting your business isn't a valid reason is arrogant and frankly stupid. Frankly, there's several other distros that don't run SeLinux and they aren't anymore problematic when properly configured than RHEL is..and they just work. Let's put the SeLinux religion aside..make it not only technically superior but actually usable and helpful and you'll see a wider adoption. The kind of arrogance I've seen in this thread is a primary reason it won't get appreciable traction outside of RHEL and why it won't be a major tool in admins toolbox inside RHEL unless folks don't NEED the flexibility Linux in general offers and SELinux restricts.
On 08/12/10 16:03, William Warren wrote:
On 12/8/2010 9:13 AM, Christopher Chan wrote:
On Wednesday, December 08, 2010 09:31 PM, Les Mikesell wrote:
On 12/8/10 4:22 AM, David Sommerseth wrote:
On 30/11/10 03:52, cpolish@surewest.net wrote:
Christopher Chan wrote:
Les Mikesell wrote:
[...snip...]
As was already mentioned in another post, run in permissive mode, for a few days if you must, and go through all the things the software does and voila! setroubleshoot and/or logs tell you what needs doing.
Very optimistic, that. In my shop, some things run annually. A comprehensive system test = production, for a year. Just this morning a 1099 (annual tax-form) script failed in test.
So you would rather disable SELinux completely - 365 days a year, rather than to switch to permissive mode when running this script once a year?
I'm sorry, but I'm not able follow that logic.
In our case if something fails once a year we lose customers and money. I'd expect that to be fairly common.
Again, that particular process is unlikely to be missed and also show to be easily mitigated by doing a realtime switch from enforcing to permissive. Such annual processes are fairly common and usually run manually. You have yet to make a compelling case for completely disabling SELinux just for this sort of thing.
loosing customers and money on an annual basis is a great reason to kill it. Make it able to work without updates interfering with a formerly running configuration on a regular basis and more folks will adopt it. Saying killing it because it is hurting your business isn't a valid reason is arrogant and frankly stupid. Frankly, there's several other distros that don't run SeLinux and they aren't anymore problematic when properly configured than RHEL is..and they just work. Let's put the SeLinux religion aside..make it not only technically superior but actually usable and helpful and you'll see a wider adoption. The kind of arrogance I've seen in this thread is a primary reason it won't get appreciable traction outside of RHEL and why it won't be a major tool in admins toolbox inside RHEL unless folks don't NEED the flexibility Linux in general offers and SELinux restricts.
And that *is* the key point! The basic SELinux stuff which most users need to know about *isn't* as hard as people want it to be. Really!! I've been fighting with it for some time, until I took the time to learn about it. After that, it's pretty much an easy breeze. My biggest mistake in my learning process was that I made SELinux much more complex and chaotic in my head than what it really is.
Anyhow, no matter which technology you're talking about, if you don't spend time learning it, it will be difficult until you learn it.
To complain about a technology as non-functional or being bothersome without having tried to learn it, is a moot argument.
Of course, there are most probably a lot of things which can make things even more intuitive. But I struggle to see those issues right now. There was a suggestion which sounds good at first glance earlier on here, that it should be a tool you could point a directory at ... and it would give some clues which files where "breaking" the file security context in the policy. That does sound like something helpful.
Otherwise, don't make SELinux more complex than what it really is. The core concept is basically a different way how to restrict access for processes - on the same level as chmod, uid/gid and ACLs does on files. SELinux only does this even more fine grained and with ways to also restrict access to other things than only file access.
"Science should explain things as simply as possible but no simpler" - Albert Einstein
Btw ... Debian 5.0 (Lenny) ships with SELinux packages installed by default, but not enabled. They seem to be moving into the SELinux direction as well. http://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html
kind regards,
David Sommerseth
[I'm guessing from the dozens of quoted lines per reply that many of y'all aren't as lucky as I am. I have a threading email reader with backing store, so I can go back and read past messages in a thread if I need more context than a brief quote can provide. I have been so lucky since the mid 90's, but I do realize that technology moves slowly into some parts of the world.]
On 12/8/2010 9:20 AM, David Sommerseth wrote:
The basic SELinux stuff which most users need to know about *isn't* as hard as people want it to be. Really!!
I'd say that any tool that reports errors with GUIDs and needs a background wizard process to turn those GUIDs into prose the system operator *might* understand is overly complex.
Security is never absolute. It is a balance between convenience and protection. I accept quite readily that some will choose not to put up with the level of inconvenience SELinux imposes.
For a similar example, observe how little-used ACLs are, especially in the *ix world. On Windows, where they're the only game in town, observe instead how rarely ACLs get changed from their defaults.
Otherwise, don't make SELinux more complex than what it really is. The core concept is basically a different way how to restrict access for processes - on the same level as chmod, uid/gid and ACLs does on files.
The trick is to make the resulting system work in obvious and intuitive ways. The original Unix file permission model is one of the many bits of genius in Unix that contributed to its success.
You'll observe by contrast that SELinux hasn't swept the Linux world, and has yet to escape into the commercial and BSD worlds. SELinux is not not an obviously-good thing, the sort of thing that spreads everywhere, quickly.
Some examples of nonintuitive SELinux behavior from my own experience:
- You install an RPM from a third party who provides a newer version of something that ships with the OS. Consequently, the OS has filesystem labels on directories used by the new RPM which are not appropriate for the newer version of the package. It fails to run. You complain on the package provider's mailing list, and they say it works for them. Later you find you need to run some obscure command to force the filesystem to relabel all these files because the package provider has SELinux turned off on their build and test systems and so doesn't ship their RPM with relabeling as part of the postinstall script.
- You install a binary library from a third party, and the program using it fails to run. Why? A required label (textrel_shlib_t) wasn't added, as happens automagically when you install libraries from an RPM instead. (Oh, and good luck remembering that obscure rule next time. I install third-party binary libraries this way maybe once a year, too rare to commit the rule to memory.)
- You're developing a web app, and the server-side tier connects to a back-end server (typical N-tier architecture) to do some work you don't want to do or can't do in PHP/Python/Perl/Ruby/whatever. Boom, you lose again, because the default httpd config prevents the web server -- or anything within that same process, like a web app -- from making outbound TCP connections, on security grounds.
- Same web app, but you make the silly mistake of wanting to install it somewhere other than /var/www/html. (Which worked in all older systems, by the way.) Oh, you silly boy! Don't you know httpd mustn't be allowed to read served files from anywhere but that one directory? Boom, you lose again.
Don't bother telling me how to fix all these, I've worked around all of them. I'm pulling them from a script I wrote specifically to apply these fixes to systems where we install our product. I'd never remember them if I had to do it manually every time we ship a system.
/That/ is my point. I could -- and sometimes do -- work around file permissions errors manually, quickly. SELinux has a higher order of complexity compared to Unix file permissions, so the associated fixes don't fit into a small, easy-to-mentally-model framework. Each fix therefore becomes a one-off that you have to write down in a document or script else you'd have to rediscover them with Google every time.
P'tui!
On 12/8/2010 3:41 PM, Warren Young wrote:
/That/ is my point. I could -- and sometimes do -- work around file permissions errors manually, quickly. SELinux has a higher order of complexity compared to Unix file permissions, so the associated fixes don't fit into a small, easy-to-mentally-model framework. Each fix therefore becomes a one-off that you have to write down in a document or script else you'd have to rediscover them with Google every time.
Is there any central reporting concept in SELinux so a multi-machine admin doesn't have to go check each for all of the one-off cases and knowledge can be shared about the fixes needed for 3rd party RPMs?
On 12/8/2010 3:26 PM, Les Mikesell wrote:
Is there any central reporting concept in SELinux so a multi-machine admin doesn't have to go check each for all of the one-off cases and knowledge can be shared about the fixes needed for 3rd party RPMs?
No. But then, there's not one for file permission errors. You handle both the same way: complain to the package providers.
The thing about SELinux here, though, is that not all package providers support SELinux, so it's easier to get them to fix a permission bug.
On 12/8/2010 4:48 PM, Warren Young wrote:
On 12/8/2010 3:26 PM, Les Mikesell wrote:
Is there any central reporting concept in SELinux so a multi-machine admin doesn't have to go check each for all of the one-off cases and knowledge can be shared about the fixes needed for 3rd party RPMs?
No. But then, there's not one for file permission errors. You handle both the same way: complain to the package providers.
But file permissions weren't added to linux as a surprising change after the applications were written so there is not the same need.
On Wednesday, December 08, 2010 11:03 PM, William Warren wrote:
On 12/8/2010 9:13 AM, Christopher Chan wrote:
On Wednesday, December 08, 2010 09:31 PM, Les Mikesell wrote:
On 12/8/10 4:22 AM, David Sommerseth wrote:
On 30/11/10 03:52, cpolish@surewest.net wrote:
Christopher Chan wrote:
Les Mikesell wrote:
[...snip...]
As was already mentioned in another post, run in permissive mode, for a few days if you must, and go through all the things the software does and voila! setroubleshoot and/or logs tell you what needs doing.
Very optimistic, that. In my shop, some things run annually. A comprehensive system test = production, for a year. Just this morning a 1099 (annual tax-form) script failed in test.
So you would rather disable SELinux completely - 365 days a year, rather than to switch to permissive mode when running this script once a year?
I'm sorry, but I'm not able follow that logic.
In our case if something fails once a year we lose customers and money. I'd expect that to be fairly common.
Again, that particular process is unlikely to be missed and also show to be easily mitigated by doing a realtime switch from enforcing to permissive. Such annual processes are fairly common and usually run manually. You have yet to make a compelling case for completely disabling SELinux just for this sort of thing. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
loosing customers and money on an annual basis is a great reason to kill it. Make it able to work without updates interfering with a formerly running configuration on a regular basis and more folks will adopt it. Saying killing it because it is hurting your business isn't a valid reason is arrogant and frankly stupid. Frankly, there's several other distros that don't run SeLinux and they aren't anymore problematic when properly configured than RHEL is..and they just work. Let's put the SeLinux religion aside..make it not only technically superior but actually usable and helpful and you'll see a wider adoption. The kind of arrogance I've seen in this thread is a primary reason it won't get appreciable traction outside of RHEL and why it won't be a major tool in admins toolbox inside RHEL unless folks don't NEED the flexibility Linux in general offers and SELinux restricts.
Please give me an example of any software stupid enough to do end-of-year processes automatically and especially financial ones that do not know how to roll back should the process fail for any reason.
Arrogance? Ha! If dissing software that take a bad approach to end-of-year processes is arrogance then so be it.
On 12/8/2010 7:13 AM, Christopher Chan wrote:
Such [periodic failures] are fairly common
I'd say the main reason someone chooses CentOS (or another Linux flavor with similar policies, like Ubuntu LTS) is that the distro provider has made a long-term support commitment with minimal churn during a major release.
This is why we tolerate the fact that CentOS 5 still ships Firefox 1.5 five years after Mozilla released it: not because we're troglodytes unwilling to upgrade, ever, but because we don't want something as random as a browser bug fix to break a formerly-working server.
and usually run manually.
I assume you mean to advocate running updates infrequently, or at least be around to fix them when the automated updates break.
If the former, you're mad if that server is exposed to the Internet. You're only slightly deranged if it's LAN-bound but in an organization large enough to support ongoing internal strife.
If the latter, that's not practical for everyone who uses CentOS. I, like many others I'm sure, support hundreds of boxes that are almost all geographically distant from me. On top of that, the vast majority of those boxes are in a different time zone, so that even though they're only used during regular business hours, those hours may occur while I'm off trying to have a life. Or sleep.
On Thursday, December 09, 2010 05:00 AM, Warren Young wrote:
On 12/8/2010 7:13 AM, Christopher Chan wrote:
Such [periodic failures] are fairly common
I'd say the main reason someone chooses CentOS (or another Linux flavor with similar policies, like Ubuntu LTS) is that the distro provider has made a long-term support commitment with minimal churn during a major release.
This is why we tolerate the fact that CentOS 5 still ships Firefox 1.5 five years after Mozilla released it: not because we're troglodytes unwilling to upgrade, ever, but because we don't want something as random as a browser bug fix to break a formerly-working server.
and usually run manually.
I assume you mean to advocate running updates infrequently, or at least be around to fix them when the automated updates break.
If the former, you're mad if that server is exposed to the Internet. You're only slightly deranged if it's LAN-bound but in an organization large enough to support ongoing internal strife.
No, I advocate setting up SELinux properly which will take care of the automatic updates. Did you miss all the pointers to using semanage so that relabels will cover your non-default necessities? And that is not just from me too.
If the latter, that's not practical for everyone who uses CentOS. I, like many others I'm sure, support hundreds of boxes that are almost all geographically distant from me. On top of that, the vast majority of those boxes are in a different time zone, so that even though they're only used during regular business hours, those hours may occur while I'm off trying to have a life. Or sleep.
See above. Again, the main issue is: Learn to use the thing properly!
On 12/8/2010 5:00 PM, Christopher Chan wrote:
On Thursday, December 09, 2010 05:00 AM, Warren Young wrote:
I assume you mean to advocate running updates infrequently,
No, I advocate setting up SELinux properly which will take care of the automatic updates.
That's great if you are wise enough to forsee all problems that an automatic update can cause.
I am not that wise.
Did you miss all the pointers to using semanage so that relabels will cover your non-default necessities? And that is not just from me too.
Yes. I will freely admit to not having read everything in this ponderous thread. :)
On Thursday, December 09, 2010 11:06 AM, Warren Young wrote:
On 12/8/2010 5:00 PM, Christopher Chan wrote:
On Thursday, December 09, 2010 05:00 AM, Warren Young wrote:
I assume you mean to advocate running updates infrequently,
No, I advocate setting up SELinux properly which will take care of the automatic updates.
That's great if you are wise enough to forsee all problems that an automatic update can cause.
I am not that wise.
Neither am I. That's why I look at the logs when something goes boom so that I can have it taken care of.
Did you miss all the pointers to using semanage so that relabels will cover your non-default necessities? And that is not just from me too.
Yes. I will freely admit to not having read everything in this ponderous thread. :)
Let me just say that the pointers I received and implemented have not given me any trouble even though the Moodle box I received from HQ has the mysql db in a non-default location and likewise the content.
I, thus, find it rather irksome when people pop up here and say SELinux is a troublesome piece of rubbish that cannot be trusted but in reality they have not got a good enough understanding of the works (and in some cases don't even try to) and so things fell apart. I did not understand SELinux at first either when it first come out but it took just one morning when I really had to get it working. In case I come across as some pompous arrogant ass, let me just say that I only got SELinux running on a Centos box very recently (Sep 2010) and so others are more qualified to advocate SELinux but it sure was NOT rocket science to make sure Moodle and Mysql in areas outside /var/lib/mysql and /var/www/html still worked.
On Wednesday, December 08, 2010 10:06:34 pm Warren Young wrote:
That's great if you are wise enough to forsee all problems that an automatic update can cause.
I am not that wise.
Nor am I; that's why I have testing server VM's on which to stage updates. Even on the production servers, thanks to them being VMware guests I can pull a snapshot prior to doing the updates, and if the update breaks things badly enough I can roll back the snapshot from VMware and triage the problem. Updates should never be blind, IMHO, especially for production servers.
That's also why I keep regular backups of my laptop; in that case I'm tracking Fedora (although I'm seriously considering purchasing RHEL Workstation), and even then I have a test desktop to see if anything major breaks. While the test desktop is not identically configured, it is close enough to be a valid test case, all the way down to the nVidia graphics.
On Thursday, December 09, 2010 11:08 PM, Lamar Owen wrote:
On Wednesday, December 08, 2010 10:06:34 pm Warren Young wrote:
That's great if you are wise enough to forsee all problems that an automatic update can cause.
I am not that wise.
Nor am I; that's why I have testing server VM's on which to stage updates. Even on the production servers, thanks to them being VMware guests I can pull a snapshot prior to doing the updates, and if the update breaks things badly enough I can roll back the snapshot from VMware and triage the problem. Updates should never be blind, IMHO, especially for production servers.
That's also why I keep regular backups of my laptop; in that case I'm tracking Fedora (although I'm seriously considering purchasing RHEL Workstation), and even then I have a test desktop to see if anything major breaks. While the test desktop is not identically configured, it is close enough to be a valid test case, all the way down to the nVidia graphics.
Yup, that's why I was basically staging for HQ so that they can implement SELinux on all the other school servers.
On Monday, November 29, 2010 12:38:20 pm Les Mikesell wrote:
[Most thrid party apps qualify as] Pretty much anything that needs to write files outside of the home directory of the owning user. Certainly anything that uses apache with its own data store.
Which is the prime target for SELinux anyway. If it runs in-process in apache you need better protection than the standard UNIX uid:gid.
All of the third-party software I run seems to run just fine, as long as the right contexts are applied.
Well, obviously it will work after someone takes the time to make it work.
Exactly. Proper information security is becoming more and more critical; educating the executive suite on the need for good information security is a big part; they're obviously going to want justification for the time spent.
If a particular app is so recalcitrant that SELinux needs to be turned off, that's when I'd be doing some drastic things, much like windows lab environments need done. Things like automatic revert to known-good snapshot on the production boxes for all but the data files. Things like isolation in a VM for those apps. Of course, that's also work, and getting SELinux working properly might be less work. Everyone wants less work per project to get more projects done, of course, but cutting corners is still cutting corners and one day it will come back to haunt the corner-cutter.
Now it is your turn to quantify: How much would you charge to teach someone to be able to make those changes and how long would it take? This has to include the ability to quickly diagnose and fix any problem that might be caused by updates to the application or to the OS distribution.
To teach, $50 per hour (if I were available to teach; at the moment I'm full on my work hours). The number of hours would depend upon the complexity of the application; for Scalix, assuming no familiarity with either Scalix or SELinux, eight to sixteen hours (one-two days). Basic stuff wouldn't take more than five to ten hours at most; but I've not done a full workup of an 'SELinux' course, either, and I bet Red Hat has; might even be something they offer, I don't know. Their instructors would likely do a much better job than I, since they teach it more often and probably more rigorous, as I don't really consider myself an expert in SELinux itself; I know enough to get my stuff to work with SELinux in enforcing/targeted mode, that's all. And I can share that experience; I can also share the experience of having been hacked once, and also the experience of multiple layers (including SELinux) preventing a hack (or two).
But training in 'SELinux did this, do that' or 'here's common symptoms of SELinux issues, and here's how to get into permissive mode so you can figure out what's breaking, and here are your triage tools' is a vital part of using SELinux to its potential.
But an ounce of prevention is worth a pound of cure; once an information theft occurs, it cannot be undone.
On 11/30/2010 9:51 AM, Lamar Owen wrote:
If a particular app is so recalcitrant that SELinux needs to be turned off, that's when I'd be doing some drastic things, much like windows lab environments need done. Things like automatic revert to known-good snapshot on the production boxes for all but the data files. Things like isolation in a VM for those apps. Of course, that's also work, and getting SELinux working properly might be less work. Everyone wants less work per project to get more projects done, of course, but cutting corners is still cutting corners and one day it will come back to haunt the corner-cutter.
Now it is your turn to quantify: How much would you charge to teach someone to be able to make those changes and how long would it take? This has to include the ability to quickly diagnose and fix any problem that might be caused by updates to the application or to the OS distribution.
To teach, $50 per hour (if I were available to teach; at the moment I'm full on my work hours). The number of hours would depend upon the complexity of the application; for Scalix, assuming no familiarity with either Scalix or SELinux, eight to sixteen hours (one-two days).
I'm not talking about a particular app. The thing I want quantified is what it will cost to train some number of people to be able to troubleshoot any problem that SELinux might cause with any app, given potential changes in updates to both the distribution provided stuff and the 3rd party coding at any time.
On Tuesday, November 30, 2010 11:21:46 am Les Mikesell wrote:
I'm not talking about a particular app. The thing I want quantified is what it will cost to train some number of people to be able to troubleshoot any problem that SELinux might cause with any app, given potential changes in updates to both the distribution provided stuff and the 3rd party coding at any time.
That I wouldn't consider myself qualified to quantify. I'm sure there are those who are, however.
On 11/30/2010 11:04 AM, Lamar Owen wrote:
On Tuesday, November 30, 2010 11:21:46 am Les Mikesell wrote:
I'm not talking about a particular app. The thing I want quantified is what it will cost to train some number of people to be able to troubleshoot any problem that SELinux might cause with any app, given potential changes in updates to both the distribution provided stuff and the 3rd party coding at any time.
That I wouldn't consider myself qualified to quantify. I'm sure there are those who are, however.
But that's the thing someone needs to be able to estimate before considering enabling SELinux on an existing farm of machines running complex, pre-existing applications where the team of operators has to be able to fix any potential problem quickly.
On Tuesday, November 30, 2010 12:18:26 pm Les Mikesell wrote:
But [what it will cost to train some number of people to be able to troubleshoot any problem that SELinux might cause with any app, given potential changes in updates to both the distribution provided stuff and the 3rd party coding at any time] is the thing someone needs to be able to estimate before considering enabling SELinux on an existing farm of machines running complex, pre-existing applications where the team of operators has to be able to fix any potential problem quickly.
Before this can be done the analysts who perform such estimating as part of their regular jobs need to become familiar with the overhead of setting up SELinux, much like any other impacting technology the analysts already deal with.
Such estimates have too many variables to state an easy answer in the general sense, especially when unknowns such as the magnitude of potential updates is factored in, or the degree of backporting of fixes into the pinned versions in an Enterprise distribution. For that matter, that is already the case in update management for some apps, so there isn't any provably major overhead adding SELinux to that mix for that particular criterion.
And is it the app causing problems with SELinux or is it SELinux causing problems with the app? Or is it the lack of integrator understanding in marrying the two? Or are the tools to configure the functionality to blame?
An integrator who as a matter of course sets SELinux to off or to permissive as one of the first steps may be in for a rude awakening as pentesters wise up to SELinux and specifically target penetration testing to that layer. Especially as empirical evidence to the utility of SELinux preventing exploitation of vulnerabilities piles up ever higher.
Upstream and CentOS both ship with SELinux in the default 'more secure' enforcing mode with the moderately strict targeted policy; to make a conscious decision to reduce security for convenience would, at least in my shop, require written justification. An analysis of the time to take to implement the controls in the app would be required at that time, as well as a risk analysis of disabling the controls. I would weigh the costs and the risks, and decide at that time what to do (as I am the decision maker in my shop, I can do that, of course).
It boils down to balancing 'it breaks my app that I can't or won't fix' against 'you've been pwned!'
Lamar Owen wrote:
On Tuesday, November 30, 2010 12:18:26 pm Les Mikesell wrote:
But [what it will cost to train some number of people to be able to troubleshoot any problem that SELinux might cause with any app, given potential changes in updates to both the distribution provided stuff and the 3rd party coding at any time] is the thing someone needs to be able to estimate before considering enabling SELinux on an existing farm of machines running complex, pre-existing applications where the team of operators has to be able to fix any potential problem quickly.
<snip>
And is it the app causing problems with SELinux or is it SELinux causing problems with the app? Or is it the lack of integrator understanding in marrying the two? Or are the tools to configure the functionality to blame?
<snip> Reality check time: selinux is a *tiny* portion of the entire Linux market, though growing. However, there are a ton of apps out there, and almost no developers who have been earning their living as programmers, who have any knowledge of selinux. Case in point: something here, developed in-house over the last 10-12 years, lots of cgi. Another case: Computer Associates' SiteMinder, big bucks commercial product.
Anyone know of a list of selinux-compatible software? And how much will the commercial software cost to upgrade it to play well with selinux? Do you have an idea of how much multiuser commercial licenses are?
mark
On Tuesday, November 30, 2010 01:55:11 pm m.roth@5-cent.us wrote:
Reality check time: selinux is a *tiny* portion of the entire Linux market, though growing.
Reality check: IDC analysts have estimated Red Hat's share of the paid commercial Linux market as 62%[1], [2], with Red Hat estimating higher [3]. That's RHEL: which ships SELinux enabled, enforcing, targeted, by default. And, this being the CentOS list, we're in a default SELinux enforcing/targeted userbase; SELinux is (in) 100% of the CentOS market, in other words. If the comparison is Ubuntu, well, I'm not so sure it so dramatically overrides, especially on the server, and maybe not even on the desktop.
However, there are a ton of apps out there, and almost no developers who have been earning their living as programmers, who have any knowledge of selinux. Case in point: something here, developed in-house over the last 10-12 years, lots of cgi. Another case: Computer Associates' SiteMinder, big bucks commercial product.
CA should know better, and if they are targeting RHEL commercially they should be supporting the default RHEL configuration.
From what I see, SELinux capability is more about packaging and is more in the policy than in the programs themselves; that is, there really shouldn't be any rewriting of apps required, just someone fingerprinting (using permissive mode and audit2allow) the application, and making a policy package for that application.
notes: [1] http://blogs.computerworld.com/14884/who_really_has_the_most_linux_users [2] http://news.cnet.com/8301-13505_3-10312978-16.html [3] http://www.internetnews.com/bus-news/article.php/3842561/Red+Hat+Were+75+of+...
Lamar Owen wrote:
On Tuesday, November 30, 2010 01:55:11 pm m.roth@5-cent.us wrote:
<snip>
However, there are a ton of apps out there, and almost no developers who have been earning their living as programmers, who have any knowledge of selinux. Case in point: something here, developed in-house over the last 10-12 years, lots of cgi. Another case: Computer Associates' SiteMinder, big bucks commercial product.
CA should know better, and if they are targeting RHEL commercially they should be supporting the default RHEL configuration.
Right. So, hey, do you have the rights to call CA and lean on them? Please? I can barely get the network folks, who actually can contact them, to understand selinux (I think of them as operators, not sysadmins).
And I notice that you don't address the other point, all the in-house apps, and if you think management will say "sure, spend whatever it takes to rewrite that so it conforms to selinux...", you're living in somewhere I don't. And just about everywhere I've worked, both as a developer and as a sysadmin had a *lot* of in-house apps.
mark
On Tuesday, November 30, 2010 03:31:44 pm m.roth@5-cent.us wrote:
Lamar Owen wrote:
CA should know better, and if they are targeting RHEL commercially they should be supporting the default RHEL configuration.
Right. So, hey, do you have the rights to call CA and lean on them?
Nope, sorry. Can't help you there.
And I notice that you don't address the other point, all the in-house apps,
In house apps must be addressed in-house; I'll address mine (and expose a smaller risk by integrating SELinux), and you or your company can address yours. I thought that was obvious enough to not require reply, as dealing with in house developers always invokes some degree of politics.
and if you think management will say "sure, spend whatever it takes to rewrite that so it conforms to selinux...", you're living in somewhere I don't. And just about everywhere I've worked, both as a developer and as a sysadmin had a *lot* of in-house apps.
We have a few; none required a rewrite; you're getting a bit melodramatic, there, as there isn't going to be any application that is going to require a complete 100% rewrite to work with SELinux.
Few required much of any thing to be changed, and even then all changes were to the filesystem labeling of the contexts. Nothing more. Not that we have a lot of in house apps; I try to do as much as possible with OOB CentOS, pulling in the bare minimum third-party stuff I can (Plone is the largest third-party app I pull in currently). But the targeted policy and Plone, to pull the biggest example, just worked fine with each other, no sweat, once I allowed zeo and the zope clients rights to bind the appropriate ports.
Lamar Owen wrote:
On Tuesday, November 30, 2010 03:31:44 pm m.roth@5-cent.us wrote:
Lamar Owen wrote:
CA should know better, and if they are targeting RHEL commercially they should be supporting the default RHEL configuration.
Right. So, hey, do you have the rights to call CA and lean on them?
Nope, sorry. Can't help you there.
So, that's out.
And I notice that you don't address the other point, all the in-house apps,
In house apps must be addressed in-house; I'll address mine (and expose a smaller risk by integrating SELinux), and you or your company can address yours. I thought that was obvious enough to not require reply, as dealing with in house developers always invokes some degree of politics.
With the developers? Ah, nope, that's *heavy* duty politics with upper management to get them to spend the money (and how does this contribute to this quarter's ROI?!?!?!)
and if you think management will say "sure, spend whatever it takes to rewrite that so it conforms to selinux...", you're living in somewhere I don't. And just about everywhere I've worked, both as a
developer and
as a sysadmin had a *lot* of in-house apps.
We have a few; none required a rewrite; you're getting a bit melodramatic, there, as there isn't going to be any application that is going to require a complete 100% rewrite to work with SELinux.
I regret to inform you there's no melodrama here. And when the codebase might be, oh, 50k, or 100k, or 250k lines, and there's all the enhancements that management (or management of other departments) want, and fixing bugs, modifying for selinux is a major budget item. <snip> mark
On 11/30/10 12:31 PM, m.roth@5-cent.us wrote:
And I notice that you don't address the other point, all the in-house apps, and if you think management will say "sure, spend whatever it takes to rewrite that so it conforms to selinux...", you're living in somewhere I don't. And just about everywhere I've worked, both as a developer and as a sysadmin had a *lot* of in-house apps.
90% of the time, you just have to reorganize the application installation directories to better suit the default settings.
for instance, all our java-ware can run just fine in /home/$APPUSER/$APPNAME and run as a regular user. if we want to put it in /opt/$COMPANY/$APP then we might have to play with selinux defaults some, since /opt isn't part of the RHEL mindset.
On Tuesday, November 30, 2010 06:04:56 pm John R Pierce wrote:
for instance, all our java-ware can run just fine in /home/$APPUSER/$APPNAME and run as a regular user. if we want to put it in /opt/$COMPANY/$APP then we might have to play with selinux defaults some, since /opt isn't part of the RHEL mindset.
Yep; Scalix plays in /opt/scalix (among others), and that was one of the things we had to address.
On Tue, Nov 30, 2010 at 03:11:24PM -0500, Lamar Owen wrote:
Reality check: IDC analysts have estimated Red Hat's share of the paid commercial Linux market as 62%[1], [2], with Red Hat estimating higher [3]. That's RHEL: which ships SELinux enabled, enforcing, targeted, by default. And, this being the CentOS list, we're in a default SELinux
Reality check: how many of those installs are RedHat OOB installs with default options? I know the 10,000 machines we have where I work are all meant to be "corporate standard" and this, by default, does _not_ have SELinux enabled.
they should be supporting the default RHEL configuration.
Shoulda, coulda, woulda... didna.
Stephen Harris wrote:
On Tue, Nov 30, 2010 at 03:11:24PM -0500, Lamar Owen wrote:
Reality check: IDC analysts have estimated Red Hat's share of the paid commercial Linux market as 62%[1], [2], with Red Hat estimating higher [3]. That's RHEL: which ships SELinux enabled, enforcing, targeted, by default. And, this being the CentOS list, we're in a default SELinux
Reality check: how many of those installs are RedHat OOB installs with default options? I know the 10,000 machines we have where I work are all meant to be "corporate standard" and this, by default, does _not_ have SELinux enabled.
And how many reset them to permissive, or off, because enforcing breaks what's been working?
And about apache... most of those attacks are preventable through defensive configuration and coding for httpd itself. Looking to selinux to protect you is very sloppy.
they should be supporting the default RHEL configuration.
Shoulda, coulda, woulda... didna.
How many folks actually use the defaults? Hell, we don't use the default partitioning scheme.
mark
On Wednesday, December 01, 2010 04:54 AM, m.roth@5-cent.us wrote:
And about apache... most of those attacks are preventable through defensive configuration and coding for httpd itself. Looking to selinux to protect you is very sloppy.
The key word is most. If one bothered to go through all the steps to lock down apache, one can also bother to apply the similar stuff with SELinux which would be must more comprehensive and take care of the other 1% or whatever cases too.
On Tuesday 30 November 2010 20:54:37 m.roth@5-cent.us wrote:
And about apache... most of those attacks are preventable through defensive configuration and coding for httpd itself. Looking to selinux to protect you is very sloppy.
So a guy in a circus, performing acrobatics on a trapeze doesn't actually ever need a safety fishnet below, right? All he needs to do is make sure never to slip, or miss to catch the trapeze bar while performing. If he isn't sloppy, he will never fall. Simple. ;-)
Best, :-) Marko
On Tue, Nov 30, 2010 at 10:28 PM, Marko Vojinovic vvmarko@gmail.com wrote:
On Tuesday 30 November 2010 20:54:37 m.roth@5-cent.us wrote:
And about apache... most of those attacks are preventable through defensive configuration and coding for httpd itself. Looking to selinux to protect you is very sloppy.
So a guy in a circus, performing acrobatics on a trapeze doesn't actually ever need a safety fishnet below, right? All he needs to do is make sure never to slip, or miss to catch the trapeze bar while performing. If he isn't sloppy, he will never fall. Simple. ;-)
Historically (although it's gotten better), the SELinux net was erected by blocking off all the ladders to the trapeze. This is great for safety of bystanders and keeping the clowns from making the trapeze slippery with cream pies, but made it hard to actually entertain the crowd. And entertaining the crowd is what a circus gets paid for.
On Wednesday, December 01, 2010 11:37 AM, Nico Kadel-Garcia wrote:
On Tue, Nov 30, 2010 at 10:28 PM, Marko Vojinovicvvmarko@gmail.com wrote:
On Tuesday 30 November 2010 20:54:37 m.roth@5-cent.us wrote:
And about apache... most of those attacks are preventable through defensive configuration and coding for httpd itself. Looking to selinux to protect you is very sloppy.
So a guy in a circus, performing acrobatics on a trapeze doesn't actually ever need a safety fishnet below, right? All he needs to do is make sure never to slip, or miss to catch the trapeze bar while performing. If he isn't sloppy, he will never fall. Simple. ;-)
Historically (although it's gotten better), the SELinux net was erected by blocking off all the ladders to the trapeze. This is great for safety of bystanders and keeping the clowns from making the trapeze slippery with cream pies, but made it hard to actually entertain the crowd. And entertaining the crowd is what a circus gets paid for.
Kinda hard to blame the net if the performers don't want to learn how to use the access ports provided to get through. Maybe the circus should think about getting performers willing to do that and not have to worry about insurance for not using a net.
On Wednesday 01 December 2010 03:37:15 Nico Kadel-Garcia wrote:
On Tue, Nov 30, 2010 at 10:28 PM, Marko Vojinovic vvmarko@gmail.com wrote:
On Tuesday 30 November 2010 20:54:37 m.roth@5-cent.us wrote:
And about apache... most of those attacks are preventable through defensive configuration and coding for httpd itself. Looking to selinux to protect you is very sloppy.
So a guy in a circus, performing acrobatics on a trapeze doesn't actually ever need a safety fishnet below, right? All he needs to do is make sure never to slip, or miss to catch the trapeze bar while performing. If he isn't sloppy, he will never fall. Simple. ;-)
Historically (although it's gotten better), the SELinux net was erected by blocking off all the ladders to the trapeze.
True, but --- as you say --- it's gotten much better since those times.
This is great for safety of bystanders and keeping the clowns from making the trapeze slippery with cream pies, but made it hard to actually entertain the crowd. And entertaining the crowd is what a circus gets paid for.
And when the guy slips off and gets killed in the middle of the performance in front of a large number of small children watching in the audience, I really wonder if that circus is going to get paid by anyone for the next performance tomorrow evening. It happens rarely, but still it does happen sometimes.
I'd still say a fishnet is a Good Idea(tm), regardless of the fact that it takes away some of the excitement during the performance. ;-)
Best, :-) Marko
On 11/30/10 9:28 PM, Marko Vojinovic wrote:
On Tuesday 30 November 2010 20:54:37 m.roth@5-cent.us wrote:
And about apache... most of those attacks are preventable through defensive configuration and coding for httpd itself. Looking to selinux to protect you is very sloppy.
So a guy in a circus, performing acrobatics on a trapeze doesn't actually ever need a safety fishnet below, right? All he needs to do is make sure never to slip, or miss to catch the trapeze bar while performing. If he isn't sloppy, he will never fall. Simple. ;-)
Analogies rarely work well, but this one would be better if you assume the crew doesn't have time to do a good job of setting up both the trapeze rigging and the net. Would you rather have a trapeze you can trust or a trapeze and a net both badly rigged and likely to break?
On Tuesday, November 30, 2010 03:49:57 pm Stephen Harris wrote:
Reality check: how many of those installs are RedHat OOB installs with default options?
No idea. How many aren't default OOB?
For that matter, how many CentOS installs are out there are set: 1.) OOB, SELinux enforcing/targeted; 2.) SELinux permissive; 3.) SELinux off; 4.) SELinux enforcing, some other policy than targeted?
I would guess no one knows. But all of my CentOS installs are OOB as concerning SELinux, except the two scalix installs, which have some custom 'stuff' thanks to the scalix instance naming.
Lamar Owen wrote:
On Tuesday, November 30, 2010 03:49:57 pm Stephen Harris wrote:
Reality check: how many of those installs are RedHat OOB installs with default options?
No idea. How many aren't default OOB?
For that matter, how many CentOS installs are out there are set: 1.) OOB, SELinux enforcing/targeted; 2.) SELinux permissive; 3.) SELinux off; 4.) SELinux enforcing, some other policy than targeted?
I would guess no one knows. But all of my CentOS installs are OOB as concerning SELinux, except the two scalix installs, which have some custom 'stuff' thanks to the scalix instance naming.
All I know is at the last two companies I worked at - AT&T, a small team building software for the NOC, a smaller root CA, and here at the federal agency I'm at, we either turned it off, or have it set to permissive.
mark
On Tue, Nov 30, 2010 at 4:19 PM, m.roth@5-cent.us wrote:
Lamar Owen wrote:
On Tuesday, November 30, 2010 03:49:57 pm Stephen Harris wrote:
Reality check: how many of those installs are RedHat OOB installs with default options?
No idea. How many aren't default OOB?
For that matter, how many CentOS installs are out there are set: 1.) OOB, SELinux enforcing/targeted; 2.) SELinux permissive; 3.) SELinux off; 4.) SELinux enforcing, some other policy than targeted?
I would guess no one knows. But all of my CentOS installs are OOB as concerning SELinux, except the two scalix installs, which have some custom 'stuff' thanks to the scalix instance naming.
All I know is at the last two companies I worked at - AT&T, a small team building software for the NOC, a smaller root CA, and here at the federal agency I'm at, we either turned it off, or have it set to permissive.
I disabled it on the last 1000 hosts *I* installed....
I would guess no one knows. But all of my CentOS installs are OOB as concerning SELinux, except the two scalix installs, which have some custom 'stuff' thanks to the scalix instance naming.
All I know is at the last two companies I worked at - AT&T, a small team building software for the NOC, a smaller root CA, and here at the federal agency I'm at, we either turned it off, or have it set to permissive.
I disabled it on the last 1000 hosts *I* installed....
Hmmm... it would be interesting take some Centos systems with production like deployments (say 3 with SELinux and 3 without) and ask a professional pen-tester to try to get into them.
Anyone willing to contribute funds (or time) to such a study? It would be educational experience and good PR, at the least.
On Wed, Dec 1, 2010 at 12:52 AM, Geoff Galitz geoff@galitz.org wrote:
I would guess no one knows. But all of my CentOS installs are OOB as concerning SELinux, except the two scalix installs, which have some custom 'stuff' thanks to the scalix instance naming.
All I know is at the last two companies I worked at - AT&T, a small team building software for the NOC, a smaller root CA, and here at the federal agency I'm at, we either turned it off, or have it set to permissive.
I disabled it on the last 1000 hosts *I* installed....
Hmmm... it would be interesting take some Centos systems with production like deployments (say 3 with SELinux and 3 without) and ask a professional pen-tester to try to get into them.
Anyone willing to contribute funds (or time) to such a study? It would be educational experience and good PR, at the least.
Oh, I know the holes and which would be straightforward to get to. There's generally enough lower hanging fruit with NFS stored passwords, email with passwords, and poorly managed elevation via SSH keys as policies before I even got there that this protection is like putting a bike lock on a jello mold.
2010/12/1 Nico Kadel-Garcia nkadel@gmail.com:
Anyone willing to contribute funds (or time) to such a study? It would be educational experience and good PR, at the least.
Oh, I know the holes and which would be straightforward to get to. There's generally enough lower hanging fruit with NFS stored passwords, email with passwords, and poorly managed elevation via SSH keys as policies before I even got there that this protection is like putting a bike lock on a jello mold.
How about production like server:
- firewall installed - selinux disabled - all services except ssh and httpd disabled -> sshd login enabled only with ssh keys and httpd protected via mod_security ? - cis hardened fixes applied to os - latest kernel patched applied
-- Eero
On this thread, I'm speaking with my manager, and the other admin comes in, ranting about selinux, and that he's going to file a bug against it with RH.... Seems he installed RHEL6, and had the misfortune of having an older Sun keyboard, and may have hit the <caps lock> key when entering the root password... and he couldn't log in. So he rebooted to single user mode, and ran passwd... which sat there for a while, then quit, with no messages. Then he turned off selinux, and passwd worked... so the whole selinux thing was a pointless and irritating exercise.
Of course, if selinux had stopped him from turning enforcing off, he'd have had to reboot from the rescue disk, at the least, and reinstall at the worst.
The bigger question is why selinux when the system is in single user mode, and offline. If someone has console access, and shouldn't have, you have management problems, not o/s security problems.
mark
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/01/2010 10:19 AM, m.roth@5-cent.us wrote:
On this thread, I'm speaking with my manager, and the other admin comes in, ranting about selinux, and that he's going to file a bug against it with RH.... Seems he installed RHEL6, and had the misfortune of having an older Sun keyboard, and may have hit the <caps lock> key when entering the root password... and he couldn't log in. So he rebooted to single user mode, and ran passwd... which sat there for a while, then quit, with no messages. Then he turned off selinux, and passwd worked... so the whole selinux thing was a pointless and irritating exercise.
Of course, if selinux had stopped him from turning enforcing off, he'd have had to reboot from the rescue disk, at the least, and reinstall at the worst.
The bigger question is why selinux when the system is in single user mode, and offline. If someone has console access, and shouldn't have, you have management problems, not o/s security problems.
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
This was a bug that has been fixed or will be fixed in the next release. Preview available in
http://people.redhat.com/dwalsh/SELinux/RHEL6/
I quit using Fedora a couple of years ago, largely because I felt as though I was being used as an SELinux guinea pig. I spent days and says trying to work around selinux problems, until I eventually just turned it off.
I'm not a professional sysadmin, but I know many of them who think SELinux is still just not workable enough for actual production systems.
I just installed the release version of RedHat 6 and wanted to use mediawiki and a couple of other CGI php programs. All of those programs that require email capability via sendmail/postfix do not work with SELINUX turned on. Some programs are nice enough to pop up a "sendmail failed" message, but not all.
type=USER_CMD msg=audit(1293752457.837:246): user pid=4383 uid=0 auid=500 ses=9 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/var/www/mediawiki116" cmd=2F62696E2F7669204C6F63616C53657474696E67732E706870 terminal=pts/4 res=success' type=AVC msg=audit(1293752692.348:247): avc: denied { search } for pid=4583 comm="sendmail" name="postfix" dev=sda2 ino=150564 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:postfix_spool_t:s0 tclass=dir type=SYSCALL msg=audit(1293752692.348:247): arch=c000003e syscall=80 success=no exit=-13 a0=7f44c0011cc0 a1=7f44c0013a00 a2=7f44c001827d a3=7fff104b7710 items=0 ppid=4410 pid=4583 auid=500 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=9 comm="sendmail" exe="/usr/sbin/sendmail.postfix" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
It is a known bugzilla, there's supposed to be some fix in the way, but it has turned into such a big hassle for us here that we've turned selinux down to PERMISSIVE mode, just so things will work.
SELINUX generates such a massive amount of output in /var/log/audit that I would never be able to notice what fails and what doesnt, some programs silently die with SELINUX rejects them. For example, I created a bunch of accounts in mediawiki that require email confirmation. Use of sendmail was rejected, (silently), and so the users's can't log in. Grrr.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/05/2011 11:50 AM, Paul Johnson wrote:
I quit using Fedora a couple of years ago, largely because I felt as though I was being used as an SELinux guinea pig. I spent days and says trying to work around selinux problems, until I eventually just turned it off.
I'm not a professional sysadmin, but I know many of them who think SELinux is still just not workable enough for actual production systems.
I just installed the release version of RedHat 6 and wanted to use mediawiki and a couple of other CGI php programs. All of those programs that require email capability via sendmail/postfix do not work with SELINUX turned on. Some programs are nice enough to pop up a "sendmail failed" message, but not all.
type=USER_CMD msg=audit(1293752457.837:246): user pid=4383 uid=0 auid=500 ses=9 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/var/www/mediawiki116" cmd=2F62696E2F7669204C6F63616C53657474696E67732E706870 terminal=pts/4 res=success' type=AVC msg=audit(1293752692.348:247): avc: denied { search } for pid=4583 comm="sendmail" name="postfix" dev=sda2 ino=150564 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:postfix_spool_t:s0 tclass=dir type=SYSCALL msg=audit(1293752692.348:247): arch=c000003e syscall=80 success=no exit=-13 a0=7f44c0011cc0 a1=7f44c0013a00 a2=7f44c001827d a3=7fff104b7710 items=0 ppid=4410 pid=4583 auid=500 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=9 comm="sendmail" exe="/usr/sbin/sendmail.postfix" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
It is a known bugzilla, there's supposed to be some fix in the way, but it has turned into such a big hassle for us here that we've turned selinux down to PERMISSIVE mode, just so things will work.
SELINUX generates such a massive amount of output in /var/log/audit that I would never be able to notice what fails and what doesnt, some programs silently die with SELINUX rejects them. For example, I created a bunch of accounts in mediawiki that require email confirmation. Use of sendmail was rejected, (silently), and so the users's can't log in. Grrr.
Turn on the httpd_can_sendmail boolean. We do not want all apache servers to be able to send mail by default.
# setsebool -P httpd_can_sendmail 1
man apache_selinux ... SELinu policy for httpd can be configured to turn on sending email. This is a security feature, since it would prevent a vulnerabiltiy in http from causing a spam attack. I certain situations, you may want http modules to send mail. You can turn on the httpd_send_mail bool? ean.
setsebool -P httpd_can_sendmail 1
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/05/2011 02:10 PM, Les Mikesell wrote:
On 1/5/2011 12:57 PM, Daniel J Walsh wrote:
man apache_selinux ...
$ man apache_selinux No manual entry for apache_selinux
???? - and I assume you wrote it...
Sorry about that, httpd_selinux
Yes I wrote it many years ago.
On Wed, Jan 5, 2011 at 12:57 PM, Daniel J Walsh dwalsh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/05/2011 11:50 AM, Paul Johnson wrote:
Turn on the httpd_can_sendmail boolean. We do not want all apache servers to be able to send mail by default.
# setsebool -P httpd_can_sendmail 1
man httpd_selinux ...
Dear Mr Walsh:
Thanks very much for the information. I did as you said, turned SELinux back on, and now mediawiki can send email, like it is supposed to!
I would not have figured it out if you had not posted your advice.
I hope this thread finds it way to google so other people will see it is a solved problem!
PJ
On 06/01/11 04:03, Paul Johnson wrote:
On Wed, Jan 5, 2011 at 12:57 PM, Daniel J Walsh dwalsh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/05/2011 11:50 AM, Paul Johnson wrote:
Turn on the httpd_can_sendmail boolean. We do not want all apache servers to be able to send mail by default.
# setsebool -P httpd_can_sendmail 1
man httpd_selinux ...
Dear Mr Walsh:
Thanks very much for the information. I did as you said, turned SELinux back on, and now mediawiki can send email, like it is supposed to!
I would not have figured it out if you had not posted your advice.
I hope this thread finds it way to google so other people will see it is a solved problem!
Whenever SELinux seems to try to bite me, I first list out all boolean settings, using grep. In your case I would do something like this:
[root@host: ~]# semanage boolean -l | grep mail allow_postfix_local_write_mail_spool -> off Allow postfix_local doma.. httpd_can_sendmail -> off Allow http daemon to send mail.. [root@host: ~]# getsebool -a | grep mail allow_postfix_local_write_mail_spool --> off httpd_can_sendmail --> off [root@host: ~]#
semanage boolean and getsebool gives basically the same information, except semanage give a little helpful description in addition.
If that's not helping, audit2why or audit2allow usually helps me to understand a little bit more what is going on. And from there I usually figure out if I need to enable more booleans or if I have a specific setup of my own which need a hand crafted SELinux module.
kind regards,
David Sommerseth
On 11/30/2010 10:42 AM, Lamar Owen wrote:
It boils down to balancing 'it breaks my app that I can't or won't fix' against 'you've been pwned!'
Actually, it boils down to 'what causes more total costs to the business'. Right now, in my experience, that is SELinux. Break ins to my servers are extremely rare (one machine out of several dozen internet exposed machines in 13 years). SELinux randomly taking out some aspect of operations is fairly frequent in comparison (several incidents on just the handful of machines I have that it was left active on).
Security in not an end unto itself. It exists to support the business making money. If a cost saving measure is costing the business more than it is saving it, it is *not* a good idea no matter how technically superior it is.
This in a very real sense is similar to the 'how much resources should measures to prevent shoplifting be given' in a retail store. If the anti-shoplifting measures are costing *more* than the shoplifting you are preventing - you have lost sight of the actual reason for anti-shoplifting measures in the first place.
Benjamin Franz wrote:
On 11/30/2010 10:42 AM, Lamar Owen wrote:
It boils down to balancing 'it breaks my app that I can't or won't fix' against 'you've been pwned!'
Actually, it boils down to 'what causes more total costs to the business'. Right now, in my experience, that is SELinux. Break ins to my
<snip>
Security in not an end unto itself. It exists to support the business making money. If a cost saving measure is costing the business more than
Not just making money, says the guy who's works for a federal contractor. It exists, in the IT world, to keep the systems working, and not corrupted.
it is saving it, it is *not* a good idea no matter how technically superior it is.
There's a story on today's slashdot, about how the terrorists have won - for *very* little money, they've cause countries and governments, esp. the US gov't, to spend hundreds of billions of dollars on prevention.
This in a very real sense is similar to the 'how much resources should measures to prevent shoplifting be given' in a retail store. If the anti-shoplifting measures are costing *more* than the shoplifting you are preventing - you have lost sight of the actual reason for anti-shoplifting measures in the first place.
Yup. Seen lots of companies do just that, or try to squeeze out the last dime... and spend dollars doing it.
mark
On Tuesday, November 30, 2010 02:04:12 pm Benjamin Franz wrote:
On 11/30/2010 10:42 AM, Lamar Owen wrote:
It boils down to balancing 'it breaks my app that I can't or won't fix' against 'you've been pwned!'
Actually, it boils down to 'what causes more total costs to the business'.
Not what causes, but what could cause, in the terms of the risk analysis. The probability of the cost is part of the equation, but in many cases it becomes 'what can a single breach cost me in the worst case' and that can outweigh what seems to be large costs. You might have a small probability of infiltration, but the cost of a single infiltration (in some areas, like healthcare and financial) can be so huge that a single infiltration could bankrupt you. If you do your online banking on your laptop, it is no stretch to say that a single infiltration of your laptop has the potential to bankrupt you, or worse. Yeah, worse: the infiltrator might be malicious enough to plant illegal material on your system and make your life really miserable, as the case of Michael Fiola showed.
And in the main SELinux integration is not a high cost. It may be in your area, but it hasn't been in mine. If it were that big of a problem, Red Hat wouldn't include it in the upstream due to customer pressure. SELinux, at least for me and others, has a very positive benefit to cost ratio. YMMV.
Security in not an end unto itself. It exists to support the business making money. If a cost saving measure is costing the business more than it is saving it, it is *not* a good idea no matter how technically superior it is.
And that's a big if. One must carefully define 'savings' in order to make an informed decision. It is a balance, that is sure.
This in a very real sense is similar to the 'how much resources should measures to prevent shoplifting be given' in a retail store. If the anti-shoplifting measures are costing *more* than the shoplifting you are preventing - you have lost sight of the actual reason for anti-shoplifting measures in the first place.
As former loss-prevention for Kmart many years ago, I know that there's more to that than economics, there's a significant public-relations piece that's difficult to impossible to quantify. And we found it difficult in the extreme to determine how much theft the visible presence of loss-prevention personnel and equipment actually prevented.
And there is an area where defense in depth is heavily practiced.
On Tuesday 30 November 2010 19:04:12 Benjamin Franz wrote:
On 11/30/2010 10:42 AM, Lamar Owen wrote:
It boils down to balancing 'it breaks my app that I can't or won't fix' against 'you've been pwned!'
Actually, it boils down to 'what causes more total costs to the business'. Right now, in my experience, that is SELinux. Break ins to my servers are extremely rare (one machine out of several dozen internet exposed machines in 13 years). SELinux randomly taking out some aspect of operations is fairly frequent in comparison (several incidents on just the handful of machines I have that it was left active on).
Security in not an end unto itself. It exists to support the business making money. If a cost saving measure is costing the business more than it is saving it, it is *not* a good idea no matter how technically superior it is.
That may be the case at the moment. But in the future you can expect that quality (of SELinux) will eventually outperform quantity (of software that doesn't support it).
Computer power is always growing, and we saw a post on this very list the other day about someone using a 5 bucks-per-hour (or so) Amazon cloud to easily crack passwords by brute force. One can expect that the number and severity of intrusions is going to rise in the future, and conventional security measures will not be enough for much long. When that time comes, you (as a sysadmin of some big corporation with a lot of in-house and third-party code running mission-critical stuff) will *want* SELinux, and you will *want* all that custom software to be SELinux compliant.
So at the moment SELinux might seem like a waste of sysadmin precious time and effort, but it is actually a wise investment to make. The sooner you learn how to make your system work with it, the better.
And developers of non-SELinux-compliant software will sooner or later find themselves under pressure to become compliant. Look what happened to oil industry --- they were actively supressing any R&D of alternative fuel sources for several decades, because it could grow to become competition for the oil money-making. And now, when the oil is running out, that same industry is investing an ever larger amount of money for that same R&D in order to save themselves from disaster.
Quantity cannot successfully suppress quality, not forever. It is always a Good Idea(tm) to embrace quality sooner, because it is an investment that will give you an edge later on.
Of course, managers and other people focused solely on money-making cannot (or don't want to) see anything beyond the next fiscal period, like governments and the election period. That kind of thinking is bound to fail at some point or produce big losses in order to survive (stockmarket crises? wars?). But sysadmins can choose not to be ignorant in this matter, so my advice is --- learn to use SELinux today, it will make your life easier tomorrow. ;-)
P.S. I am just waiting for the day when SELinux is going to become locked in enforcing mode by the kernel developers, much as the traditional permissions system is a mandatory thing right now. :-D
Best, :-) Marko
On 11/30/2010 3:13 PM, Marko Vojinovic wrote:
P.S. I am just waiting for the day when SELinux is going to become locked in enforcing mode by the kernel developers, much as the traditional permissions system is a mandatory thing right now. :-D
I thought there was a security API in the kernel that was designed specifically _not_ to lock it to an implementation. Is there a standards group for SELinux? It's one thing to follow Posix, something else to be locked to a non-standard concept.
On Tuesday, November 30, 2010 04:52:42 pm Les Mikesell wrote:
I thought there was a security API in the kernel that was designed specifically _not_ to lock it to an implementation.
Yes; Linux Security Modules (LSM). According to the wikipedia.org page on said subject, the current 'officially' recognized modules are: AppArmor, SELinux, SMACK, and TOMOYO Linux.
Is there a standards group for SELinux? It's one thing to follow Posix, something else to be locked to a non-standard concept.
Hmmm, https://security.wiki.kernel.org/index.php/Projects seems to be the place to look for information on the general topic of security (and lists more modules than the Wikipedia article referenced above). The SELinux site itself is selinuxproject.org which has a lot of information; quite a bit updated since the last time I looked.
It's as standard as pretty much any other open source project; there have been several developer summits, for instance, and it has some well established commercial players working together. But if you're looking for an ISO or ANSI or IEEE committee, no, none that I can tell. Nor is there one for the Linux kernel, or for glibc, for that matter. Or TCP/IP, either.
On 30/11/10 17:21, Les Mikesell wrote:
On 11/30/2010 9:51 AM, Lamar Owen wrote:
If a particular app is so recalcitrant that SELinux needs to be turned off, that's when I'd be doing some drastic things, much like windows lab environments need done. Things like automatic revert to known-good snapshot on the production boxes for all but the data files. Things like isolation in a VM for those apps. Of course, that's also work, and getting SELinux working properly might be less work. Everyone wants less work per project to get more projects done, of course, but cutting corners is still cutting corners and one day it will come back to haunt the corner-cutter.
Now it is your turn to quantify: How much would you charge to teach someone to be able to make those changes and how long would it take? This has to include the ability to quickly diagnose and fix any problem that might be caused by updates to the application or to the OS distribution.
To teach, $50 per hour (if I were available to teach; at the moment I'm full on my work hours). The number of hours would depend upon the complexity of the application; for Scalix, assuming no familiarity with either Scalix or SELinux, eight to sixteen hours (one-two days).
I'm not talking about a particular app. The thing I want quantified is what it will cost to train some number of people to be able to troubleshoot any problem that SELinux might cause with any app, given potential changes in updates to both the distribution provided stuff and the 3rd party coding at any time.
https://www.redhat.com/courses/rhs429_red_hat_enterprise_selinux_policy_administration/
Complete this one with the exam, and you're certified on SELinux on RHEL.
It might be other offerings as well, but I don't know about those.
kind regards,
David Sommerseth
On 12/8/10 4:42 AM, David Sommerseth wrote:
On 30/11/10 17:21, Les Mikesell wrote:
On 11/30/2010 9:51 AM, Lamar Owen wrote:
If a particular app is so recalcitrant that SELinux needs to be turned off, that's when I'd be doing some drastic things, much like windows lab environments need done. Things like automatic revert to known-good snapshot on the production boxes for all but the data files. Things like isolation in a VM for those apps. Of course, that's also work, and getting SELinux working properly might be less work. Everyone wants less work per project to get more projects done, of course, but cutting corners is still cutting corners and one day it will come back to haunt the corner-cutter.
Now it is your turn to quantify: How much would you charge to teach someone to be able to make those changes and how long would it take? This has to include the ability to quickly diagnose and fix any problem that might be caused by updates to the application or to the OS distribution.
To teach, $50 per hour (if I were available to teach; at the moment I'm full on my work hours). The number of hours would depend upon the complexity of the application; for Scalix, assuming no familiarity with either Scalix or SELinux, eight to sixteen hours (one-two days).
I'm not talking about a particular app. The thing I want quantified is what it will cost to train some number of people to be able to troubleshoot any problem that SELinux might cause with any app, given potential changes in updates to both the distribution provided stuff and the 3rd party coding at any time.
https://www.redhat.com/courses/rhs429_red_hat_enterprise_selinux_policy_administration/
Complete this one with the exam, and you're certified on SELinux on RHEL.
It might be other offerings as well, but I don't know about those.
Thanks - $3K and 4 days per operator and perhaps some developers seems like a reasonable starting point to consider - on top of an RHCE.
Lamar Owen wrote:
On Monday, November 29, 2010 11:29:31 am Les Mikesell wrote:
Agreed, but not everyone has time to do both - or to learn lots of distribution-specific details in mixed environments. My opinion is that doing the simple stuff first is a win. And that works the same on systems that don't include SELinux.
<snip>
Security isn't simple. The mantra 'just disable SELinux, you don't need it anyway because it's too big of a pain and apps that aren't part of the tested distribution can break' is oversimplifying a complex issue. My opinion is that I'm not going to run third party apps that break in that way, and I'm going to let the developers know why.
<snip> That's fine for you. When you're running in a larger environment, as many of us are, corporate or government, and you have no choice in what's run, esp. if some of it's run by mandate, and the group mandating it only knows WinDoze, and companies that they buy software from claim they have it for Linux (like CA), or you've got F/OSS that no one has time to do more than customize, not go through zillions of lines of code, that generate AVC's, you do what we do: mostly permissive.
mark
On Monday, November 29, 2010 02:24:14 pm m.roth@5-cent.us wrote:
Lamar Owen wrote:
My opinion is that I'm not going to run third party apps that break in that way, and I'm going to let the developers know why.
<snip> That's fine for you. When you're running in a larger environment, as many of us are, corporate or government, and you have no choice in what's run, esp. if some of it's run by mandate, and the group mandating it only knows WinDoze, and companies that they buy software from claim they have it for Linux (like CA), or you've got F/OSS that no one has time to do more than customize, not go through zillions of lines of code, that generate AVC's, you do what we do: mostly permissive.
While I sympathize with the plight of those saddled with software not written with SELinux in mind, I would ask those so saddled to understand that others are running enforcing mode SELinux systems with no trouble at all.
And most cases where I've needed to troubleshoot AVC's they've been file labels, and didn't require going through zillions of lines of code to fix.
But the basic real trouble is that the upstream developers cannot fix bugs that they don't know about. Now perhaps they don't care about SELinux; well, at that point I would hazard to say that perhaps you should just run whatever is best supported by upstream, whether that be SuSE, of debian, or whatever.
On 11/28/2010 09:31 AM, Benjamin Franz wrote:
[...] And then, one day, it won't work. Worse - it doesn't always *log* what it is doing in a way that you can figure out. Occasionally not at all. So you spend a few hours poking at the system until you try the magic of turning off SELinux. And then it starts working again.
My experience is that *unless you have a system configured exactly like the defaults*, SELinux is prone to suddenly deciding after an update that it doesn't like your configuration anymore. Once because an update to SELinux changed the labeling on an existing directory tree - blowing away my own applied labeling with no warning. And there are even RH supplied rpms that *do not work* with SELinux without being SELinux being tweaked first.
And in an exact example of this, today I needed to update some WordPress (WP) installations. Only, for "some reason" the FTP based autoupdater didn't work today.
You guessed it - SELinux had struck again. I have left SELinux active on this machine because I don't trust WP not to get hacked. I went out of my way to make the system as SELinux friendly as I could when I built it because of this. It has had SELinux active right from the start.
But something in the normal yum system updates or other routine system operation over the last several months apparently caused the system to mis-label part of the directory tree making it so that FTP (which is only allowed from the localhost to support WP updating) could no longer access some directory trees. No idea why: I'm the only person who has logged into the machine since March - and I only log in to run updates. It worked on April 26th - but not today.
My fix today? I temporarily disabled SELinux, ran the WP updates, touched /.autorelabel and rebooted the machine. And "mysteriously" the FTP problem is gone now. This isn't the first time this has happened on this machine.
If I wasn't so specifically paranoid about WP, SELinux would be disabled on this machine as well.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/02/2010 06:34 PM, Jerry Franz wrote:
On 11/28/2010 09:31 AM, Benjamin Franz wrote:
[...] And then, one day, it won't work. Worse - it doesn't always *log* what it is doing in a way that you can figure out. Occasionally not at all. So you spend a few hours poking at the system until you try the magic of turning off SELinux. And then it starts working again.
My experience is that *unless you have a system configured exactly like the defaults*, SELinux is prone to suddenly deciding after an update that it doesn't like your configuration anymore. Once because an update to SELinux changed the labeling on an existing directory tree - blowing away my own applied labeling with no warning. And there are even RH supplied rpms that *do not work* with SELinux without being SELinux being tweaked first.
And in an exact example of this, today I needed to update some WordPress (WP) installations. Only, for "some reason" the FTP based autoupdater didn't work today.
You guessed it - SELinux had struck again. I have left SELinux active on this machine because I don't trust WP not to get hacked. I went out of my way to make the system as SELinux friendly as I could when I built it because of this. It has had SELinux active right from the start.
But something in the normal yum system updates or other routine system operation over the last several months apparently caused the system to mis-label part of the directory tree making it so that FTP (which is only allowed from the localhost to support WP updating) could no longer access some directory trees. No idea why: I'm the only person who has logged into the machine since March - and I only log in to run updates. It worked on April 26th - but not today.
My fix today? I temporarily disabled SELinux, ran the WP updates, touched /.autorelabel and rebooted the machine. And "mysteriously" the FTP problem is gone now. This isn't the first time this has happened on this machine.
If I wasn't so specifically paranoid about WP, SELinux would be disabled on this machine as well.
Did you take a look at the AVC messages? Are you running setroubleshoot?
Usually running something like restorecon -R -v /var/ftp would have cleaned this up, if it is a simple mislabel in /var directory.
On 12/06/2010 06:06 AM, Daniel J Walsh wrote:
Did you take a look at the AVC messages? Are you running setroubleshoot?
Yes to both.
Usually running something like restorecon -R -v /var/ftp would have cleaned this up, if it is a simple mislabel in /var directory.
The point is *I shouldn't have to*. A stable system should not have breakages from SELinux where 'for some reason' a directory tree got mislabeled during updates. And yet it does. I enable SELinux on only a handful of my systems - and most of those systems acquire SELinux related problems at least once ever year or two just from normal updates.
While SELinux continues to do stuff like this, it will remain disabled on the vast majority of my (and many other people's) systems.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/06/2010 09:45 AM, Jerry Franz wrote:
On 12/06/2010 06:06 AM, Daniel J Walsh wrote:
Did you take a look at the AVC messages? Are you running setroubleshoot?
Yes to both.
Usually running something like restorecon -R -v /var/ftp would have cleaned this up, if it is a simple mislabel in /var directory.
The point is *I shouldn't have to*. A stable system should not have breakages from SELinux where 'for some reason' a directory tree got mislabeled during updates. And yet it does. I enable SELinux on only a handful of my systems - and most of those systems acquire SELinux related problems at least once ever year or two just from normal updates.
While SELinux continues to do stuff like this, it will remain disabled on the vast majority of my (and many other people's) systems.
I agree, and would like to look at the AVC's to understand what could have broken the labeling.
On 12/06/2010 06:47 AM, Daniel J Walsh wrote:
I agree, and would like to look at the AVC's to understand what could have broken the labeling
Well - since it happened again this morning, here you go. On further investigation in backups, I previously had the user account that I use for the FTP based update with its home directory set to a location inside the /var/www/html tree. Since that unknowingly passed this rule, it silently worked. It was changed to a /home/ based directory instead a while ago - tripping this rule. But not consistently: FTP appears to at least partially work outside the home tree even with the rule active.
I *really* dislike landmines when doing routine system tasks.
Dec 7 07:14:19 10.96.1.9 setroubleshoot: SELinux is preventing the ftp daemon from writing files outside the home directory (./upgrade). For complete SELinux messages. run sealert -l e7787694-644e-4e4e-9b45-bd86c7eb33ce
sealert -l e7787694-644e-4e4e-9b45-bd86c7eb33ce
Summary:
SELinux is preventing the ftp daemon from writing files outside the home directory (./upgrade).
Detailed Description:
SELinux has denied the ftp daemon write access to directories outside the home directory (./upgrade). Someone has logged in via your ftp daemon and is trying to create or write a file. If you only setup ftp to allow anonymous ftp, this could signal a intrusion attempt.
Allowing Access:
If you do not want SELinux preventing ftp from writing files anywhere on the system you need to turn on the allow_ftpd_full_access boolean: "setsebool -P allow_ftpd_full_access=1"
The following command will allow this access:
setsebool -P allow_ftpd_full_access=1
Additional Information:
Source Context system_u:system_r:ftpd_t Target Context system_u:object_r:httpd_sys_content_t Target Objects ./upgrade [ dir ] Source vsftpd Source Path /usr/sbin/vsftpd Port <Unknown> Host XXXXXXXXXXXXXX Source RPM Packages vsftpd-2.1.0-2 Target RPM Packages Policy RPM selinux-policy-2.4.6-279.el5_5.2 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name allow_ftpd_full_access Host Name XXXXXXXXXXXXX Platform Linux XXXXXXXXXXXX 2.6.18-194.26.1.el5 #1 SMP Tue Nov 9 12:54:40 EST 2010 i686 i686 Alert Count 17 First Seen Thu Dec 2 12:10:14 2010 Last Seen Tue Dec 7 07:14:19 2010 Local ID e7787694-644e-4e4e-9b45-bd86c7eb33ce Line Numbers
Raw Audit Messages
host=XXXXXXXXXXXXXXXXXXXX type=AVC msg=audit(1291734859.344:6678): avc: denied { write } for pid=1018 comm="vsftpd" name="upgrade" dev=dm-5 ino=1926503 scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=dir
host=XXXXXXXXXXXXXXXXXXXX type=SYSCALL msg=audit(1291734859.344:6678): arch=40000003 syscall=39 success=no exit=-13 a0=8e340d0 a1=1ff a2=802330 a3=1 items=0 ppid=1014 pid=1018 auid=502 uid=502 gid=100 euid=502 suid=502 fsuid=502 egid=100 sgid=100 fsgid=100 tty=(none) ses=1017 comm="vsftpd" exe="/usr/sbin/vsftpd" subj=system_u:system_r:ftpd_t:s0 key=(null)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/07/2010 10:36 AM, Benjamin Franz wrote:
On 12/06/2010 06:47 AM, Daniel J Walsh wrote:
I agree, and would like to look at the AVC's to understand what could have broken the labeling
Well - since it happened again this morning, here you go. On further investigation in backups, I previously had the user account that I use for the FTP based update with its home directory set to a location inside the /var/www/html tree. Since that unknowingly passed this rule, it silently worked. It was changed to a /home/ based directory instead a while ago - tripping this rule. But not consistently: FTP appears to at least partially work outside the home tree even with the rule active.
I *really* dislike landmines when doing routine system tasks.
Dec 7 07:14:19 10.96.1.9 setroubleshoot: SELinux is preventing the ftp daemon from writing files outside the home directory (./upgrade). For complete SELinux messages. run sealert -l e7787694-644e-4e4e-9b45-bd86c7eb33ce
sealert -l e7787694-644e-4e4e-9b45-bd86c7eb33ce
Summary:
SELinux is preventing the ftp daemon from writing files outside the home directory (./upgrade).
Detailed Description:
SELinux has denied the ftp daemon write access to directories outside the home directory (./upgrade). Someone has logged in via your ftp daemon and is trying to create or write a file. If you only setup ftp to allow anonymous ftp, this could signal a intrusion attempt.
Allowing Access:
If you do not want SELinux preventing ftp from writing files anywhere on the system you need to turn on the allow_ftpd_full_access boolean: "setsebool -P allow_ftpd_full_access=1"
The following command will allow this access:
setsebool -P allow_ftpd_full_access=1
Additional Information:
Source Context system_u:system_r:ftpd_t Target Context system_u:object_r:httpd_sys_content_t Target Objects ./upgrade [ dir ] Source vsftpd Source Path /usr/sbin/vsftpd Port <Unknown> Host XXXXXXXXXXXXXX Source RPM Packages vsftpd-2.1.0-2 Target RPM Packages Policy RPM selinux-policy-2.4.6-279.el5_5.2 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name allow_ftpd_full_access Host Name XXXXXXXXXXXXX Platform Linux XXXXXXXXXXXX 2.6.18-194.26.1.el5 #1 SMP Tue Nov 9 12:54:40 EST 2010 i686 i686 Alert Count 17 First Seen Thu Dec 2 12:10:14 2010 Last Seen Tue Dec 7 07:14:19 2010 Local ID e7787694-644e-4e4e-9b45-bd86c7eb33ce Line Numbers
Raw Audit Messages
host=XXXXXXXXXXXXXXXXXXXX type=AVC msg=audit(1291734859.344:6678): avc: denied { write } for pid=1018 comm="vsftpd" name="upgrade" dev=dm-5 ino=1926503 scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=dir
host=XXXXXXXXXXXXXXXXXXXX type=SYSCALL msg=audit(1291734859.344:6678): arch=40000003 syscall=39 success=no exit=-13 a0=8e340d0 a1=1ff a2=802330 a3=1 items=0 ppid=1014 pid=1018 auid=502 uid=502 gid=100 euid=502 suid=502 fsuid=502 egid=100 sgid=100 fsgid=100 tty=(none) ses=1017 comm="vsftpd" exe="/usr/sbin/vsftpd" subj=system_u:system_r:ftpd_t:s0 key=(null)
Where is the directory upgrade located. SELinux is complaining about the ftp site writing to a directory labeled as apache content (httpd_sys_content_t. The way we usually handle shared data between "sharing domains" is to label the content public_content_rw_t. The following man pages explain these labels.
man ftpd_selinux man httpd_selinux
On 12/07/2010 07:36 AM, Benjamin Franz wrote:
On 12/06/2010 06:47 AM, Daniel J Walsh wrote:
I agree, and would like to look at the AVC's to understand what could have broken the labeling
Well - since it happened again this morning, here you go. On further investigation in backups, I previously had the user account that I use for the FTP based update with its home directory set to a location inside the /var/www/html tree. Since that unknowingly passed this rule, it silently worked. It was changed to a /home/ based directory instead a while ago - tripping this rule. But not consistently: FTP appears to at least partially work outside the home tree even with the rule active.
I *really* dislike landmines when doing routine system tasks.
Ok. SELinux blew up something else that was previously working on that machine (yes - I've already done something to fix it for now. I don't need anyone saying 'well run sealert'. Been there - done that. Things are running now.) This repeated time suckage is why people routinely turn it off.
sealert -l e6e017f5-9c2b-4e7b-895e-51a232042588
Summary:
SELinux is preventing the httpd from using potentially mislabeled files /var/XXXXXXXXXX/misc/manage_clients/config.xml (var_t).
Detailed Description:
SELinux has denied the httpd access to potentially mislabeled files /var/XXXXXXXXXX/misc/manage_clients/config.xml. This means that SELinux will not allow httpd to use these files. Many third party apps install html files in directories that SELinux policy cannot predict. These directories have to be labeled with a file context which httpd can access.
Allowing Access:
If you want to change the file context of /var/XXXXXXXXXX/misc/manage_clients/config.xml so that the httpd daemon can access it, you need to execute it using chcon -t httpd_sys_content_t '/var/XXXXXXXXXX/misc/manage_clients/config.xml'. You can look at the httpd_selinux man page for additional information.
Additional Information:
Source Context system_u:system_r:httpd_t Target Context user_u:object_r:var_t Target Objects /var/XXXXXXXXXX/misc/manage_clients/config.xml [ file ] Source httpd Source Path /usr/sbin/httpd Port <Unknown> Host XXXXXXXXXX Source RPM Packages httpd-2.2.3-43.el5.centos.3 Target RPM Packages Policy RPM selinux-policy-2.4.6-279.el5_5.2 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name httpd_bad_labels Host Name XXXXXXXXXX Platform Linux XXXXXXXXXX 2.6.18-194.26.1.el5 #1 SMP Tue Nov 9 12:54:40 EST 2010 i686 i686 Alert Count 3 First Seen Mon Apr 26 10:20:36 2010 Last Seen Tue Dec 7 07:38:17 2010 Local ID e6e017f5-9c2b-4e7b-895e-51a232042588 Line Numbers
Raw Audit Messages
host=XXXXXXXXXX type=AVC msg=audit(1291736297.720:6786): avc: denied { getattr } for pid=21363 comm="httpd" path="/var/XXXXXXXXXX/misc/manage_clients/config.xml" dev=dm-0 ino=5355222 scontext=system_u:system_r:httpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file
host=XXXXXXXXXX type=SYSCALL msg=audit(1291736297.720:6786): arch=40000003 syscall=195 success=no exit=-13 a0=82e7380 a1=8297c68 a2=296ff4 a3=82e7380 items=0 ppid=3398 pid=21363 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0 key=(null)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/07/2010 10:59 AM, Benjamin Franz wrote:
On 12/07/2010 07:36 AM, Benjamin Franz wrote:
On 12/06/2010 06:47 AM, Daniel J Walsh wrote:
I agree, and would like to look at the AVC's to understand what could have broken the labeling
Well - since it happened again this morning, here you go. On further investigation in backups, I previously had the user account that I use for the FTP based update with its home directory set to a location inside the /var/www/html tree. Since that unknowingly passed this rule, it silently worked. It was changed to a /home/ based directory instead a while ago - tripping this rule. But not consistently: FTP appears to at least partially work outside the home tree even with the rule active.
I *really* dislike landmines when doing routine system tasks.
Ok. SELinux blew up something else that was previously working on that machine (yes - I've already done something to fix it for now. I don't need anyone saying 'well run sealert'. Been there - done that. Things are running now.) This repeated time suckage is why people routinely turn it off.
sealert -l e6e017f5-9c2b-4e7b-895e-51a232042588
Summary:
SELinux is preventing the httpd from using potentially mislabeled files /var/XXXXXXXXXX/misc/manage_clients/config.xml (var_t).
Detailed Description:
SELinux has denied the httpd access to potentially mislabeled files /var/XXXXXXXXXX/misc/manage_clients/config.xml. This means that SELinux will not allow httpd to use these files. Many third party apps install html files in directories that SELinux policy cannot predict. These directories have to be labeled with a file context which httpd can access.
Allowing Access:
If you want to change the file context of /var/XXXXXXXXXX/misc/manage_clients/config.xml so that the httpd daemon can access it, you need to execute it using chcon -t httpd_sys_content_t '/var/XXXXXXXXXX/misc/manage_clients/config.xml'. You can look at the httpd_selinux man page for additional information.
Additional Information:
Source Context system_u:system_r:httpd_t Target Context user_u:object_r:var_t Target Objects /var/XXXXXXXXXX/misc/manage_clients/config.xml [ file ] Source httpd Source Path /usr/sbin/httpd Port <Unknown> Host XXXXXXXXXX Source RPM Packages httpd-2.2.3-43.el5.centos.3 Target RPM Packages Policy RPM selinux-policy-2.4.6-279.el5_5.2 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name httpd_bad_labels Host Name XXXXXXXXXX Platform Linux XXXXXXXXXX 2.6.18-194.26.1.el5 #1 SMP Tue Nov 9 12:54:40 EST 2010 i686 i686 Alert Count 3 First Seen Mon Apr 26 10:20:36 2010 Last Seen Tue Dec 7 07:38:17 2010 Local ID e6e017f5-9c2b-4e7b-895e-51a232042588 Line Numbers
Raw Audit Messages
host=XXXXXXXXXX type=AVC msg=audit(1291736297.720:6786): avc: denied { getattr } for pid=21363 comm="httpd" path="/var/XXXXXXXXXX/misc/manage_clients/config.xml" dev=dm-0 ino=5355222 scontext=system_u:system_r:httpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file
host=XXXXXXXXXX type=SYSCALL msg=audit(1291736297.720:6786): arch=40000003 syscall=195 success=no exit=-13 a0=82e7380 a1=8297c68 a2=296ff4 a3=82e7380 items=0 ppid=3398 pid=21363 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0 key=(null)
Yes SELinux and all MAC systems require that if the administrator puts files in non default directories, then they have to have to be told. In the case of SELinux, this involves correcting the labeling. DAC has similar problems, in that you need to make sure the permission flags and ownership is correct. Of course admins have been dealing with DAC for years so they understand it, and the number of UID/Permision combinations is more limited then the amounts of labels that SELinux presents.
I wrote this paper to try to explain what SELinux tends to complain about.
http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/selinux_four_t...
On 12/07/2010 08:12 AM, Daniel J Walsh wrote:
Yes SELinux and all MAC systems require that if the administrator puts files in non default directories, then they have to have to be told. In the case of SELinux, this involves correcting the labeling. DAC has similar problems, in that you need to make sure the permission flags and ownership is correct. Of course admins have been dealing with DAC for years so they understand it, and the number of UID/Permision combinations is more limited then the amounts of labels that SELinux presents.
I wrote this paper to try to explain what SELinux tends to complain about.
http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/selinux_four_t...
The fact remains that as the old saw goes: Make it hard enough to do something and people will quit doing it.
SELinux remains *hard* for most non-default users. As the lead SE developer, things you find utterly routine and only slightly annoying are major roadblocks to many other people. You aren't the average user. You aren't even close to one. A *sophisticated* user will see the suggestion given by sealeart to run chcon, follow it, *and have no idea that a system relabel can screw it up again*. sealert doesn't even mention the issue! It is as if the person who wrote the sealert messages never considered that people would like things fixed permanently rather than just until the next SELinux update relabels the system.
I have 15 years experience running Linux servers. And I find SELinux damn annoying. I can work with it at need - but I'm generally pissed off when I find 'yet another SELinux issue'. My boss, who is the fallback admin here, would find it utterly opaque. He would have no idea where to even start looking for an SELinux issue.
The issue is similar to that of using passwords of more than 10 characters composed of random mixed-case alphanumeric characters (ideally with special characters mixed in). Yes - they are provably more secure in a technical sense than virtually any easily remembered system. However *real people* have to use the passwords. And they will put the damn things on taped notes on the bottom of their laptop if you make them too hard (not conjectural - I've caught people here doing exactly that).
BTW: You have a typographical error on your semanage example. You don't have a closing ' character on the file_spec.
The issue is similar to that of using passwords of more than 10 characters composed of random mixed-case alphanumeric characters (ideally with special characters mixed in). Yes - they are provably more secure in a technical sense than virtually any easily remembered system. However *real people* have to use the passwords. And they will put the damn things on taped notes on the bottom of their laptop if you make them too hard (not conjectural - I've caught people here doing exactly that).
My solution is to use complex passwords, and write them down wrong, making my write-down a password hint, but not a password. My task is to remember what is my transform from hint to fact: (examples follow, choose your own) 1: Spell the 2 words in the password in English, but In the password use g33kp3ak on one of the words and alternating case on the other. 2: The numbers and shifted-numbers (e.g. 2 and @ on my US keyboard) in the password are swapped from the hint: the '@' in the hint is a 2 in password ... Or are they NOT case-shifted but instead position-shifted one to the right or left? Once I have a simple transform memorized, written password hints aren't much use to the on-site attacker who has access to my machine. Word-for-word transforms within context are also possible
The hint of 1red9football;; becomes !ReD8f00tb411::
I think this meets the 'memorizable' need and strength-of-password need.
This is only vaguely a CentOS issue. More to the CentOS point, IPv4 still words, so behind-the-firewall networks can still use it with utter abandon. Mapping internal IPv4 addresses to publicly-visible IPv6 addresses is a routing issue. How good is Linux/RH/CentOS with V6-to-V4-and-back address-type mapping? ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/07/2010 11:59 AM, Benjamin Franz wrote:
On 12/07/2010 08:12 AM, Daniel J Walsh wrote:
Yes SELinux and all MAC systems require that if the administrator puts files in non default directories, then they have to have to be told. In the case of SELinux, this involves correcting the labeling. DAC has similar problems, in that you need to make sure the permission flags and ownership is correct. Of course admins have been dealing with DAC for years so they understand it, and the number of UID/Permision combinations is more limited then the amounts of labels that SELinux presents.
I wrote this paper to try to explain what SELinux tends to complain about.
http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/selinux_four_t...
The fact remains that as the old saw goes: Make it hard enough to do something and people will quit doing it.
SELinux remains *hard* for most non-default users. As the lead SE developer, things you find utterly routine and only slightly annoying are major roadblocks to many other people. You aren't the average user. You aren't even close to one. A *sophisticated* user will see the suggestion given by sealeart to run chcon, follow it, *and have no idea that a system relabel can screw it up again*. sealert doesn't even mention the issue! It is as if the person who wrote the sealert messages never considered that people would like things fixed permanently rather than just until the next SELinux update relabels the system.
I have 15 years experience running Linux servers. And I find SELinux damn annoying. I can work with it at need - but I'm generally pissed off when I find 'yet another SELinux issue'. My boss, who is the fallback admin here, would find it utterly opaque. He would have no idea where to even start looking for an SELinux issue.
The issue is similar to that of using passwords of more than 10 characters composed of random mixed-case alphanumeric characters (ideally with special characters mixed in). Yes - they are provably more secure in a technical sense than virtually any easily remembered system. However *real people* have to use the passwords. And they will put the damn things on taped notes on the bottom of their laptop if you make them too hard (not conjectural - I've caught people here doing exactly that).
BTW: You have a typographical error on your semanage example. You don't have a closing ' character on the file_spec.
I am not arguing that SELinux is easy, I am arguing that it is not rocket science. I have worked for a several years to try to make SELinux easier to use, while making it more comprehensive and adding tools like svirt and sandbox to give administrators more tools to secure their systems. We have fixed thousands of bugs in policy and applications that were acting bad, so I have seen the problems people have had with SELinux, I am encouraged by the number of people who have worked with SELinux and continue to leave SELinux enabled by default. But I understand why SELinux is disabled on some machines.
RHEL6 SELinux usability compared to RHEL4 is light years better. But setting up security on a computer system is hard. Then there is always the battle between greater security versus decrease in usability as you illustrate in your password example.
http://danwalsh.livejournal.com/2008/10/22/
We have a new version of setroubleshoot which will hopefully be far easier to understand and will recommend the proper commands to setup labeling versus using chcon. We will hopefully be back porting this to RHEl6.
Having people work with us to fix issues by reporting bugs, submitting patches and any other help is greatly appreciated.
Daniel J Walsh wrote:
On 12/07/2010 11:59 AM, Benjamin Franz wrote:
On 12/07/2010 08:12 AM, Daniel J Walsh wrote:
Yes SELinux and all MAC systems require that if the administrator puts files in non default directories, then they have to have to be told. In the case of SELinux, this involves correcting the labeling. DAC has
<snip>
I wrote this paper to try to explain what SELinux tends to complain about.
http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/selinux_four_t...
The fact remains that as the old saw goes: Make it hard enough to do something and people will quit doing it.
SELinux remains *hard* for most non-default users. As the lead SE
<snip>
I have 15 years experience running Linux servers. And I find SELinux
Ditto, and that's also Solaris and Tru-64.
damn annoying. I can work with it at need - but I'm generally pissed off when I find 'yet another SELinux issue'. My boss, who is the fallback admin here, would find it utterly opaque. He would have no idea where to even start looking for an SELinux issue.
Yup. <snip>
I am not arguing that SELinux is easy, I am arguing that it is not rocket science. I have worked for a several years to try to make
If rocket science means very difficult and obscure, yes, it is.
SELinux easier to use, while making it more comprehensive and adding tools like svirt and sandbox to give administrators more tools to secure their systems. We have fixed thousands of bugs in policy and applications that were acting bad, so I have seen the problems people have had with SELinux, I am encouraged by the number of people who have worked with SELinux and continue to leave SELinux enabled by default. But I understand why SELinux is disabled on some machines.
<snip> What have you done for folks who have third-party software, either F/OSS or COTS, or in-house developed stuff, *none* of which was written with selinux in mind, and is *not* going to be rewritten any time soon? You've seen me on the selinux list, and I have yet to figure out why I see the complaints about contexts, since they *appear* to be temp files, and I don't know where they're located, or where the CGI scripts are that create them are, and *all* of it's got the added complexity that some of that are on NFS-mounted directories.
mark
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/07/2010 12:46 PM, m.roth@5-cent.us wrote:
Daniel J Walsh wrote:
On 12/07/2010 11:59 AM, Benjamin Franz wrote:
On 12/07/2010 08:12 AM, Daniel J Walsh wrote:
Yes SELinux and all MAC systems require that if the administrator puts files in non default directories, then they have to have to be told. In the case of SELinux, this involves correcting the labeling. DAC has
<snip> >>> I wrote this paper to try to explain what SELinux tends to complain >>> about. >>> >>> http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/selinux_four_things.pdf >> >> The fact remains that as the old saw goes: Make it hard enough to do >> something and people will quit doing it. >> >> SELinux remains *hard* for most non-default users. As the lead SE <snip> >> I have 15 years experience running Linux servers. And I find SELinux
Ditto, and that's also Solaris and Tru-64.
damn annoying. I can work with it at need - but I'm generally pissed off when I find 'yet another SELinux issue'. My boss, who is the fallback admin here, would find it utterly opaque. He would have no idea where to even start looking for an SELinux issue.
Yup.
<snip> > I am not arguing that SELinux is easy, I am arguing that it is not > rocket science. I have worked for a several years to try to make
If rocket science means very difficult and obscure, yes, it is.
SELinux easier to use, while making it more comprehensive and adding tools like svirt and sandbox to give administrators more tools to secure their systems. We have fixed thousands of bugs in policy and applications that were acting bad, so I have seen the problems people have had with SELinux, I am encouraged by the number of people who have worked with SELinux and continue to leave SELinux enabled by default. But I understand why SELinux is disabled on some machines.
<snip> What have you done for folks who have third-party software, either F/OSS or COTS, or in-house developed stuff, *none* of which was written with selinux in mind, and is *not* going to be rewritten any time soon? You've seen me on the selinux list, and I have yet to figure out why I see the complaints about contexts, since they *appear* to be temp files, and I don't know where they're located, or where the CGI scripts are that create them are, and *all* of it's got the added complexity that some of that are on NFS-mounted directories.
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
We have attempted to work with them, setup default labeling for them when we know about the problems, embarrass them when they say you need to disable SELInux. Red Hat is working on new developer tools to help third party developers work on RHEL systems. I am not sure what else I can do to get them to work with the security systems in place on RHEL.
Daniel J Walsh wrote:
On 12/07/2010 12:46 PM, m.roth@5-cent.us wrote:
Daniel J Walsh wrote:
On 12/07/2010 11:59 AM, Benjamin Franz wrote:
On 12/07/2010 08:12 AM, Daniel J Walsh wrote:
<mvnch>
What have you done for folks who have third-party software, either F/OSS or COTS, or in-house developed stuff, *none* of which was written with selinux in mind, and is *not* going to be rewritten any time soon? You've seen me on the selinux list, and I have yet to figure out why I
see the
complaints about contexts, since they *appear* to be temp files, and I don't know where they're located, or where the CGI scripts are that create them are, and *all* of it's got the added complexity that some
of that
are on NFS-mounted directories.
We have attempted to work with them, setup default labeling for them when we know about the problems, embarrass them when they say you need to disable SELInux. Red Hat is working on new developer tools to help third party developers work on RHEL systems. I am not sure what else I can do to get them to work with the security systems in place on RHEL.
Ok, it's good to know you are thinking about that. How 'bout a tool, point it at a directory, and it reports only the files/directories that are default, or break policy, or that *might* suggest where there's a problem (scripts in this directory will write default_t if they run anywhere but /here/ohly/, etc?
mark
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/07/2010 01:13 PM, m.roth@5-cent.us wrote:
Daniel J Walsh wrote:
On 12/07/2010 12:46 PM, m.roth@5-cent.us wrote:
Daniel J Walsh wrote:
On 12/07/2010 11:59 AM, Benjamin Franz wrote:
On 12/07/2010 08:12 AM, Daniel J Walsh wrote:
<mvnch> >> What have you done for folks who have third-party software, either F/OSS >> or COTS, or in-house developed stuff, *none* of which was written with >> selinux in mind, and is *not* going to be rewritten any time soon? >> You've seen me on the selinux list, and I have yet to figure out why I see the >> complaints about contexts, since they *appear* to be temp files, and I >> don't know where they're located, or where the CGI scripts are that >> create them are, and *all* of it's got the added complexity that some of that >> are on NFS-mounted directories. > > We have attempted to work with them, setup default labeling for them > when we know about the problems, embarrass them when they say you need > to disable SELInux. Red Hat is working on new developer tools to help > third party developers work on RHEL systems. I am not sure what else I > can do to get them to work with the security systems in place on RHEL.
Ok, it's good to know you are thinking about that. How 'bout a tool, point it at a directory, and it reports only the files/directories that are default, or break policy, or that *might* suggest where there's a problem (scripts in this directory will write default_t if they run anywhere but /here/ohly/, etc?
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I think you would need to further explain. We can tell you what file directory is mislabeled
# restorecon -R -N -v PATH
We can tell which types have access to which types
seseach -A -s httpd_t -t default_t
Are you looking for something like
What access does /usr/bin/httpd have to /myweb/html? What types does /usr/bin/httpd have write access to?
On 12/7/10 11:53 AM, Daniel J Walsh wrote:
We have attempted to work with them, setup default labeling for them when we know about the problems, embarrass them when they say you need to disable SELInux. Red Hat is working on new developer tools to help third party developers work on RHEL systems. I am not sure what else I can do to get them to work with the security systems in place on RHEL.
Ummm, get a standards body to ratify it...
On Tue, 7 Dec 2010, m.roth@5-cent.us wrote:
I am not arguing that SELinux is easy, I am arguing that it is not rocket science. I have worked for a several years to try to make
If rocket science means very difficult and obscure, yes, it is.
I've got to cry "foul" here. "Difficult and obscure" can be applied to just about any *nix command-line utility (or Windows registry hack, or Mac OpenDirectory tweak, ...).
I don't consider SELinux any more difficult to understand and manage than other Linux security-related controls like iptables or extended ACLs. That isn't to say that my mother-in-law would take to it, but I'd expect any sysadmin on my IT staff to be able to learn it.
In that sense, it's certainly not rocket science.
Daniel's other point concerns increased usability.
I've been using SELinux for a while now -- not always successfully, and I certainly do NOT consider myself an expert -- and it's quite apparent to me that the folks at Red Hat have unquestionably made it easier to use over that time.
It's apparently quite difficult to write policies for some applications (*cough* Nagios) that want to do a ton of things -- and third-party or in-house apps have a different set of challenges -- but I can't imagine anyone claiming that there hasn't been marked progress in SELinux usability over the CentOS 4 -> 5 life cycles.
On Tuesday 07 December 2010 16:59:22 Benjamin Franz wrote:
On 12/07/2010 08:12 AM, Daniel J Walsh wrote:
Yes SELinux and all MAC systems require that if the administrator puts files in non default directories, then they have to have to be told. In the case of SELinux, this involves correcting the labeling. DAC has similar problems, in that you need to make sure the permission flags and ownership is correct. Of course admins have been dealing with DAC for years so they understand it, and the number of UID/Permision combinations is more limited then the amounts of labels that SELinux presents.
The fact remains that as the old saw goes: Make it hard enough to do something and people will quit doing it.
Precisely --- make it hard enough for people to keep files in non-default location, and use the broken/unsafe configuration of various services, and eventually people will learn how to do things properly. ;-)
SELinux remains *hard* for most non-default users. As the lead SE developer, things you find utterly routine and only slightly annoying are major roadblocks to many other people. You aren't the average user. You aren't even close to one. A *sophisticated* user will see the suggestion given by sealeart to run chcon, follow it, *and have no idea that a system relabel can screw it up again*. sealert doesn't even mention the issue! It is as if the person who wrote the sealert messages never considered that people would like things fixed permanently rather than just until the next SELinux update relabels the system.
Oh, come on, any "sophisticated" user will RTFM !! Hopefully *before* executing anything completely blindly, as root.
Just man semanage and man restorecon. How hard can that be?!
I have 15 years experience running Linux servers. And I find SELinux damn annoying. I can work with it at need - but I'm generally pissed off when I find 'yet another SELinux issue'. My boss, who is the fallback admin here, would find it utterly opaque. He would have no idea where to even start looking for an SELinux issue.
Two man pages are too hard for your boss to read and understand?! I find it hard to believe that any tech-savvy admin is too incompetent to learn how to use a new tool (any new tool, including SELinux). Computers in general are a fast-moving target, and people who cannot keep up should get retired and find something else to do, or hire someone to help/teach them.
I find the slow adoption of SELinux to be a psychological rather than a technical issue. Once, out of nowhere, there just appeared this new thing, going by the name "Security Enhanced Linux", and it tells people in the face that the way they configured their systems for the past n years is unsafe, insecure, full of security holes and a Bad Idea in general. And since their ego gets hurt in the process, they choose to disable SELinux rather than learn how to use it properly.
On that note, I know people who still routinely log into X as root, and refuse to acknowledge that it is a Very Bad Idea. Just look at the mess in Windows world --- there *are* proper user accounts with limited permissions and all, quite available and easy to configure. And how many people bother to use them? It's much easier to just be root, right? Why bother with all that permissions stuff? After all, it's so utterly opaque to any sophisticated user, right? My boss would never even think of executing "ls -l" to check for proper file permissions, let alone read a manual for chmod and chown...
I mean, what are we talking about here? SELinux is another security layer, and it reduces the number of wrong ways you can configure your system. And if you insist to do things in the wrong way, it yells at you and you need to decide what to do about it (either shut it up or reconfigure things properly). Every serious admin finds such a tool quite useful, at least as a real-time guide to proper system configuration, let alone intrusion prevention mechanism.
And it isn't really rocket science. It's just an extension to the existing classical permissions system --- it works in analogous way, just with greater flexibility and power. If you know how to understand and use file permissions, you will easily grasp all about SELinux.
And if you are running 3rd party software which isn't SELinux aware, you have several choices, in order of preference:
1) contact the software devs and complain that their software is broken 2) contact your boss and tell him that running such software is bad for securuty and that he should consider migrating to something with better support 3) use semanage, restorecon, audit2allow to modify the local policy, and have your boss sign a document releasing you of any responsibility if an intrusion happens through this vector 4) run SELinux in permissive mode, and try to learn from the alerts about all the things your system is doing wrong 5) disable SELinux and be ignorant about security.
If you choose 5), feel free to also disable iptables, log in as root all the time, and make sure that the root password is clearly visible on the company website. Why bother with all that stuff, anyway? ;-)
HTH, :-) Marko
On 12/7/10 1:45 PM, Marko Vojinovic wrote:
And it isn't really rocket science. It's just an extension to the existing classical permissions system --- it works in analogous way, just with greater flexibility and power. If you know how to understand and use file permissions, you will easily grasp all about SELinux.
No, it doesn't have much in common with the standard uid/gid based permissioning system.
- disable SELinux and be ignorant about security.
If you choose 5), feel free to also disable iptables, log in as root all the time, and make sure that the root password is clearly visible on the company website. Why bother with all that stuff, anyway? ;-)
I think you've missed the point that 'all that stuff' (being traditional unix security mechanisms) are not all that insecure. It is only when you get them wrong that you need to fall back on selinux as a safety net. And if you can't get the simple version right, how can you hope to do it right with something wildly more complicated?
On Tuesday 07 December 2010 23:29:44 Les Mikesell wrote:
On 12/7/10 1:45 PM, Marko Vojinovic wrote:
And it isn't really rocket science. It's just an extension to the existing classical permissions system --- it works in analogous way, just with greater flexibility and power. If you know how to understand and use file permissions, you will easily grasp all about SELinux.
No, it doesn't have much in common with the standard uid/gid based permissioning system.
Of course, it's different, but the idea is the same --- both a process and a file have a set of labels (flags, owner, group, SELinux context). On each access attempt, these labels are checked for "compatibility" one by one (old permissions first, SELinux policy second). If all the flags are "compatible", access is allowed. Otherwise it is denied.
On this elementary descriptive level both DAC and MAC systems appear pretty identical. Of course, if you go into the details, they're quite different, SELinux offering way more flexibility in policy creation and enforcement, but the typical admin doesn't actually need to be aware of these differences --- if the system denies access to something, you should first try to understand why and maybe adapt to the proper service usage/configuration. And if you are absolutely sure that this access should be allowed, you can always just go and adjust the labels (flags, owner&group, context) to make it work. Use chmod, chown, chgrp, chcon to fix whatever needs fixing. Once that is done, you should use semanage to make the chcon changes persistent, if you wish. From an admin POV, absolutely no operational difference.
In the vast majority of cases, the admin typically doesn't need to know any more than this, and SELinux can be regarded just as a more intricate set of labels, in addition to the usual traditional ones.
- disable SELinux and be ignorant about security.
If you choose 5), feel free to also disable iptables, log in as root all the time, and make sure that the root password is clearly visible on the company website. Why bother with all that stuff, anyway? ;-)
I think you've missed the point that 'all that stuff' (being traditional unix security mechanisms) are not all that insecure. It is only when you get them wrong that you need to fall back on selinux as a safety net. And if you can't get the simple version right, how can you hope to do it right with something wildly more complicated?
My comment was ironic --- the point is that if you decide you don't need one security layer, why don't you decide that you actually don't need another, and another, and... all of them?
Disabling SELinux is the same type of decision as disabling the firewall --- it's there to protect you, yet you don't know how to properly configure it and use it, furthermore you don't want to bother to learn, so you simply disable the thing that's getting in your way and preventing you from doing what you want (which is typically very stupid securitywise, but ignorant don't care anyway...).
And I could argue that iptables configuration is at least equally complex as SELinux configuration. They're even similar in design --- one filters network access, the other filters file access. One has a set of rules (tables) to determine what is allowed, the other also has a set of rules (policy) to determine what is allowed. In order to tweak one you need to read and understand man iptables, while in order to tweak the other you need to read and undestand man semanage (restorecon is quite trivial once you grasp this). One comes with a reasonable default configuration, the other also comes with a reasonable default configuration.
The only major difference I see is that setroubleshoot will visibly yell at you if something generates an AVC denial, while iptables will silently do its thing and let you ponder on why your favorite app doesn't want to establish a connection... I wonder if there is an analogous alert tool that would wreck havoc on the screen when some packet is dropped by iptables, and telling you the exact syntax for the iptables command you need to execute if you want to allow that access. Come to think of it, such a tool might actually be useful in some cases. :-)
So I would expect the admin who disables SELinux by default to also disable the firewall by default --- they both get in your way, especially if you use some 3rd party software that requires both of them to be custom-configured.
But I don't see anyone suggesting that disabling the firewall would be a good idea, so why disable SELinux then? Once you go down the "I don't need this security layer" road, where do you stop, and why? My advise is --- don't even start going down that road, rather invest some time and learn how to use SELinux, just as you have invested some time in the past and learned how to use chmod, chown and iptables.
Best, :-) Marko
On 12/7/10 8:28 PM, Marko Vojinovic wrote:
I think you've missed the point that 'all that stuff' (being traditional unix security mechanisms) are not all that insecure. It is only when you get them wrong that you need to fall back on selinux as a safety net. And if you can't get the simple version right, how can you hope to do it right with something wildly more complicated?
My comment was ironic --- the point is that if you decide you don't need one security layer, why don't you decide that you actually don't need another, and another, and... all of them?
Well, one reason might be that you've used those other standards-ratified layers for decades and the only problems you've ever had were caused by stupid programming. So you don't expect adding another layer of programming that isn't standardized across platforms to solve all your problems.
Disabling SELinux is the same type of decision as disabling the firewall --- it's there to protect you, yet you don't know how to properly configure it and use it, furthermore you don't want to bother to learn, so you simply disable the thing that's getting in your way and preventing you from doing what you want (which is typically very stupid securitywise, but ignorant don't care anyway...).
Or you might use a hardware firewall platform so you don't have to deal with all the bizarrely different ways every system you touch handles software firewalling.
And I could argue that iptables configuration is at least equally complex as SELinux configuration.
Agreed, and something that equally needs standardization.
So I would expect the admin who disables SELinux by default to also disable the firewall by default --- they both get in your way, especially if you use some 3rd party software that requires both of them to be custom-configured.
No, I would expect the admin who disables SELinux to be managing thousands of machines, many different OS versions, with programs from hundreds of sources running on them, with those hundreds of software sources not catering to the non-standard needs of one particular platform.
But I don't see anyone suggesting that disabling the firewall would be a good idea, so why disable SELinux then? Once you go down the "I don't need this security layer" road, where do you stop, and why?
Anyone who started before SELinux was around is probably quite comfortable without it. And perhaps the same for iptables or software/host based firewalls, though not firewalling in general.
On 08/12/10 04:28, Les Mikesell wrote:
On 12/7/10 8:28 PM, Marko Vojinovic wrote:
I think you've missed the point that 'all that stuff' (being traditional unix security mechanisms) are not all that insecure. It is only when you get them wrong that you need to fall back on selinux as a safety net. And if you can't get the simple version right, how can you hope to do it right with something wildly more complicated?
My comment was ironic --- the point is that if you decide you don't need one security layer, why don't you decide that you actually don't need another, and another, and... all of them?
Well, one reason might be that you've used those other standards-ratified layers for decades and the only problems you've ever had were caused by stupid programming. So you don't expect adding another layer of programming that isn't standardized across platforms to solve all your problems.
Ehm ... is iptables a ratified standard across platforms? SELinux is basically a kind of iptables, but oriented against restricting file/network call/system call/process/etc accesses locally on the box.
Disabling SELinux is the same type of decision as disabling the firewall --- it's there to protect you, yet you don't know how to properly configure it and use it, furthermore you don't want to bother to learn, so you simply disable the thing that's getting in your way and preventing you from doing what you want (which is typically very stupid securitywise, but ignorant don't care anyway...).
Or you might use a hardware firewall platform so you don't have to deal with all the bizarrely different ways every system you touch handles software firewalling.
You still need to learn how to use that hardware firewall, though.
And I could argue that iptables configuration is at least equally complex as SELinux configuration.
Agreed, and something that equally needs standardization.
iptables is a de-facto standard on all Linux distributions nowadays. It is not ratified by ISO, IETF or similar ... but how does that make the real life scenario any different? That's just a piece of paper. iptables works, and so does SELinux - when you learn how to use it.
So I would expect the admin who disables SELinux by default to also disable the firewall by default --- they both get in your way, especially if you use some 3rd party software that requires both of them to be custom-configured.
No, I would expect the admin who disables SELinux to be managing thousands of machines, many different OS versions, with programs from hundreds of sources running on them, with those hundreds of software sources not catering to the non-standard needs of one particular platform.
SELinux is another layer of security. It's not the only security layer. If an admin decides to disable SELinux due to having too much to manage already, that's that admins choice. However, it is still not recommendable to trade security for simplicity.
But I don't see anyone suggesting that disabling the firewall would be a good idea, so why disable SELinux then? Once you go down the "I don't need this security layer" road, where do you stop, and why?
Anyone who started before SELinux was around is probably quite comfortable without it. And perhaps the same for iptables or software/host based firewalls, though not firewalling in general.
SELinux came as a result that someone found weaknesses and wanted to try avoid security issues. Just like when firewalls began to become so popular 20-30 years ago or so. There was a need to improve something, and someone did the job. Nobody cared much about firewalls in the early 80's. Why? Maybe because nobody thought anyone would abuse or misuse the network infrastructure?
SELinux has been around for about a decade or so. And I believe that the more widespread SELinux becomes, and the more users it gets, the more people will not understand such discussions like this.
I remember in the early days when I found ipfwadm difficult, but I tackled it in the end. Then ipchains came, and the same round again. Then iptables came, which was easier due to the similarity to ipchains. Nowadays, I don't have any issues with iptables at all, and find it like a breeze to play with. And there's probably plenty of similar things - configuring MySQL and PostgreSQL, setting up Apache securely, DNS/BIND configurations. You start from scratch, and begin to learn.
I remember I found SELinux tricky and difficult. Then I learnt more about it, and guess what - it's no magic for me any more. It's actually fairly simple to use for me. And I'm no SELinux developer. But I'm happily running SELinux on about all of the 12-15 boxes which is under my control. Yes, AVC's happens ... but I've learnt how to read them and understand them, then I understand what is happening and know what I can do about it ... just as I had to do the same when looking at iptables/ipchains LOG entries. In the beginning, it was less understandable - now I barely understand I struggled with it in the beginning.
But unless you *invest time* to learn the tools ... you'll only be frustrated that something doesn't work. And some people find it easier to give up and just disable it ... just like some people even did with firewalling in the early days.
kind regards,
David Sommerseth
On 12/8/2010 4:04 AM, David Sommerseth wrote:
Disabling SELinux is the same type of decision as disabling the firewall --- it's there to protect you, yet you don't know how to properly configure it and use it, furthermore you don't want to bother to learn, so you simply disable the thing that's getting in your way and preventing you from doing what you want (which is typically very stupid securitywise, but ignorant don't care anyway...).
Or you might use a hardware firewall platform so you don't have to deal with all the bizarrely different ways every system you touch handles software firewalling.
You still need to learn how to use that hardware firewall, though.
Our network group is much smaller than the group that installs and maintains servers, so specialized knowledge about one specific product is not so unreasonable. Plus, code updates to networking equipment are rare and breaking existing configurations almost unheard of. And changing the firewall platform has no side effects on any applications that might be running on the network behind them.
Agreed, and something that equally needs standardization.
iptables is a de-facto standard on all Linux distributions nowadays. It is not ratified by ISO, IETF or similar ... but how does that make the real life scenario any different? That's just a piece of paper. iptables works, and so does SELinux - when you learn how to use it.
The real life situation is that iptables only works on linux and the way it works is distribution-dependent. So what you learn may lock you into a platform that may not always be your best choice.
SELinux came as a result that someone found weaknesses and wanted to try avoid security issues. Just like when firewalls began to become so popular 20-30 years ago or so. There was a need to improve something, and someone did the job. Nobody cared much about firewalls in the early 80's. Why? Maybe because nobody thought anyone would abuse or misuse the network infrastructure?
Does that mean you would not be comfortable moving your applications to SUSE, Solaris, OS X, Windows, etc.? I don't want that kind of lock-in.
SELinux has been around for about a decade or so. And I believe that the more widespread SELinux becomes, and the more users it gets, the more people will not understand such discussions like this.
Agreed - if it is as standard and cross-platform as Posix support you will be able to depend on it without the associated side effect of being locked to a particular OS distribution.
On 08/12/10 17:10, Les Mikesell wrote:
On 12/8/2010 4:04 AM, David Sommerseth wrote:
[...snip...]
Agreed, and something that equally needs standardization.
iptables is a de-facto standard on all Linux distributions nowadays. It is not ratified by ISO, IETF or similar ... but how does that make the real life scenario any different? That's just a piece of paper. iptables works, and so does SELinux - when you learn how to use it.
The real life situation is that iptables only works on linux and the way it works is distribution-dependent. So what you learn may lock you into a platform that may not always be your best choice.
Please educate me here. I've been using Novell SuSE Linux, RHEL/CentOS/Fedora, Gentoo, Crux Linux, RootLinux, Slackware, Ubuntu and my N900's maemo5 which is Debian based and OpenWRT based routers ... and I have not seen iptables behave differently than expected on any of these ... I don't completely understand your argument.
Some of these distroes does indeed have their own additional tools, like YaST2, ufw, system-config-firewall, etc, etc ... That will be different, but they all use iptables under the hood. I'm not talking about the simplified iptables front-end, as that *is* expected to be different.
SELinux came as a result that someone found weaknesses and wanted to try avoid security issues. Just like when firewalls began to become so popular 20-30 years ago or so. There was a need to improve something, and someone did the job. Nobody cared much about firewalls in the early 80's. Why? Maybe because nobody thought anyone would abuse or misuse the network infrastructure?
Does that mean you would not be comfortable moving your applications to SUSE, Solaris, OS X, Windows, etc.? I don't want that kind of lock-in.
Considering Debian is on the move towards SELinux (Lenny installs SELinux packages by default, just not enabled by default), openSuSE is moving towards SELinux[1], Gentoo have hardened/SELinux projects going on ... so moving from RHEL/CentOS to other Linux distros will not be an issue in the future. Since I see that SELinux do begin to get some traction in other distroes as well, so I am not worried about a "lock-in" on SELinux.
When it comes to Solaris, OSX and Windows, that is not comparable, as when you base your installations on Linux, you already at that point to limit yourself somewhat. And those OSes got completely other security mechanisms. If they are comparable, better or worse than SELinux, I don't know - because I prefer Linux in general - as it is a F/OSS product. But with the knowledge I now have with SELinux, I would be reluctant to move over to a platform which do not have something similar.
[1] http://news.opensuse.org/2008/08/20/opensuse-to-add-selinux-basic-enablement-in-111/
SELinux has been around for about a decade or so. And I believe that the more widespread SELinux becomes, and the more users it gets, the more people will not understand such discussions like this.
Agreed - if it is as standard and cross-platform as Posix support you will be able to depend on it without the associated side effect of being locked to a particular OS distribution.
First of all SELinux is written for Linux. Or else it would probably have been called SEPosix.
Second, iptables is a de-facto standard for Linux, just as pf is pretty much the standard firewalling on BSD. Windows and Solaris got their own firewalling methods as well. My point is, neither of them are any Posix standards ... would you prefer to not use any of these firewall implementations due to lack of cross-platform Posix support?
kind regards,
David Sommerseth
On 12/8/2010 12:55 PM, David Sommerseth wrote:
The real life situation is that iptables only works on linux and the way it works is distribution-dependent. So what you learn may lock you into a platform that may not always be your best choice.
Please educate me here. I've been using Novell SuSE Linux, RHEL/CentOS/Fedora, Gentoo, Crux Linux, RootLinux, Slackware, Ubuntu and my N900's maemo5 which is Debian based and OpenWRT based routers ... and I have not seen iptables behave differently than expected on any of these ... I don't completely understand your argument.
Some of these distroes does indeed have their own additional tools, like YaST2, ufw, system-config-firewall, etc, etc ... That will be different, but they all use iptables under the hood. I'm not talking about the simplified iptables front-end, as that *is* expected to be different.
How many of those use the same commands to start/stop/save-current-config? Where do they keep the configs? How If you deployed applications on all of them, how much time would it take to train the operators that do the install and maintenance to deal with all the variations? What if you switch to Solaris or a *bsd version? These aren't so much an issue if you use separate hardware for firewalling as when you run the host firewall on every device.
Does that mean you would not be comfortable moving your applications to SUSE, Solaris, OS X, Windows, etc.? I don't want that kind of lock-in.
When it comes to Solaris, OSX and Windows, that is not comparable, as when you base your installations on Linux, you already at that point to limit yourself somewhat.
But most applications aren't, and shouldn't be restricted to Linux. Something in java in particular is equally at home on about any OS. And most of our servers are not currently Linux.
Agreed - if it is as standard and cross-platform as Posix support you will be able to depend on it without the associated side effect of being locked to a particular OS distribution.
First of all SELinux is written for Linux. Or else it would probably have been called SEPosix.
Second, iptables is a de-facto standard for Linux, just as pf is pretty much the standard firewalling on BSD. Windows and Solaris got their own firewalling methods as well. My point is, neither of them are any Posix standards ... would you prefer to not use any of these firewall implementations due to lack of cross-platform Posix support?
I think it is fine that non-standards-conforming things exist. I just like to avoid them as much as possible myself - and certainly to avoid having them intimately intertwined with applications that would otherwise be portable.
On Thursday, December 09, 2010 03:40 AM, Les Mikesell wrote:
How many of those use the same commands to start/stop/save-current-config? Where do they keep the configs? How If you deployed applications on all of them, how much time would it take to train the operators that do the install and maintenance to deal with all the variations? What if you switch to Solaris or a *bsd version? These aren't so much an issue if you use separate hardware for firewalling as when you run the host firewall on every device.
I think it is fine that non-standards-conforming things exist. I just like to avoid them as much as possible myself - and certainly to avoid having them intimately intertwined with applications that would otherwise be portable.
At least you are consistent in not using every layer available to you. How about you be more consistent by advocating the non-use of iptables and the use of hardware firewall because iptables is non-standard too?
Or rather stop telling people not to use SELinux and iptables on this list just because you don't want to use any of these tools because it is too troublesome for you and your gang.
On 12/8/2010 6:14 PM, Christopher Chan wrote:
On Thursday, December 09, 2010 03:40 AM, Les Mikesell wrote:
Or rather stop telling people not to use SELinux and iptables on this list just because you don't want to use any of these tools because it is too troublesome for you and your gang.
I've never told anyone not to do anything. I've described circumstances where it is not practical. Not everyone has the same circumstances.
On Thursday, December 09, 2010 08:41 AM, Les Mikesell wrote:
On 12/8/2010 6:14 PM, Christopher Chan wrote:
On Thursday, December 09, 2010 03:40 AM, Les Mikesell wrote:
Or rather stop telling people not to use SELinux and iptables on this list just because you don't want to use any of these tools because it is too troublesome for you and your gang.
I've never told anyone not to do anything. I've described circumstances where it is not practical. Not everyone has the same circumstances.
I see. I got the impression that you were supporting certain detractors of SELinux who advocate disabling it. I guess you are just playing the devil's advocate as a sounding board. My apologies then for the mislabel and allow me to relabel.
On Thursday, December 09, 2010 02:55 AM, David Sommerseth wrote:
Second, iptables is a de-facto standard for Linux, just as pf is pretty much the standard firewalling on BSD. Windows and Solaris got their own firewalling methods as well. My point is, neither of them are any Posix standards ... would you prefer to not use any of these firewall implementations due to lack of cross-platform Posix support?
Ah...I believe it is ipfw that is standard on the BSDs although pf has been ported to FreeBSD...
On 09/12/10 01:05, Christopher Chan wrote:
On Thursday, December 09, 2010 02:55 AM, David Sommerseth wrote:
Second, iptables is a de-facto standard for Linux, just as pf is pretty much the standard firewalling on BSD. Windows and Solaris got their own firewalling methods as well. My point is, neither of them are any Posix standards ... would you prefer to not use any of these firewall implementations due to lack of cross-platform Posix support?
Ah...I believe it is ipfw that is standard on the BSDs although pf has been ported to FreeBSD...
You might be pretty much right. The *BSD does have several firewall solutions, some unique to some *BSDs and some available to most of the BSD flavours, and I might have confused it. Thanks for straiten me out!
kind regards,
David Sommerseth
On Wed, Dec 8, 2010 at 11:10 AM, Les Mikesell lesmikesell@gmail.com wrote:
On 12/8/2010 4:04 AM, David Sommerseth wrote:
iptables is a de-facto standard on all Linux distributions nowadays. It is not ratified by ISO, IETF or similar ... but how does that make the real life scenario any different? That's just a piece of paper. iptables works, and so does SELinux - when you learn how to use it.
The real life situation is that iptables only works on linux and the way it works is distribution-dependent. So what you learn may lock you into a platform that may not always be your best choice.
iptables rules are distribution-independent. Different distributions dump the iptables control and config files in different locations...
SELinux came as a result that someone found weaknesses and wanted to try avoid security issues. Just like when firewalls began to become so popular 20-30 years ago or so. There was a need to improve something, and someone did the job. Nobody cared much about firewalls in the early 80's. Why? Maybe because nobody thought anyone would abuse or misuse the network infrastructure?
Does that mean you would not be comfortable moving your applications to SUSE, Solaris, OS X, Windows, etc.? I don't want that kind of lock-in.
SUSE has apparmor (which it considers equivalent/superior) but you probably can install selinux on it (you can on Ubuntu and Debian).
Solaris has Trusted Extensions for MAC and RBAC.
OS X has a Macified version of TrustedBSD.
Windows has UAC.
(In the same way that the last three have their own firewall apps!)
On Thursday, December 09, 2010 11:39 PM, Tom H wrote:
SELinux came as a result that someone found weaknesses and wanted to try avoid security issues. Just like when firewalls began to become so popular 20-30 years ago or so. There was a need to improve something, and someone did the job. Nobody cared much about firewalls in the early 80's. Why? Maybe because nobody thought anyone would abuse or misuse the network infrastructure?
Does that mean you would not be comfortable moving your applications to SUSE, Solaris, OS X, Windows, etc.? I don't want that kind of lock-in.
SUSE has apparmor (which it considers equivalent/superior) but you probably can install selinux on it (you can on Ubuntu and Debian).
Solaris has Trusted Extensions for MAC and RBAC.
OS X has a Macified version of TrustedBSD.
Windows has UAC.
(In the same way that the last three have their own firewall apps!)
and FreeBSD has TrustedBSD on by default now.
On 12/8/2010 3:04 AM, David Sommerseth wrote:
it is still not recommendable to trade security for simplicity.
Security is never an absolute, is *always* a tradeoff against simplicity.
We could store our servers 16 feet underground and encased in concrete to prevent tampering and accidental power cycling. We don't do that because union labor makes digging them back out when we really do intentionally want to power cycle them or perform physical maintenance impractical.
Security is a continuum. One should rationally choose where along it one wants to be. There are defensible, rational reasons to choose to disable SELinux.
On 08/12/10 23:01, Warren Young wrote:
On 12/8/2010 3:04 AM, David Sommerseth wrote:
it is still not recommendable to trade security for simplicity.
Security is never an absolute, is *always* a tradeoff against simplicity.
We could store our servers 16 feet underground and encased in concrete to prevent tampering and accidental power cycling. We don't do that because union labor makes digging them back out when we really do intentionally want to power cycle them or perform physical maintenance impractical.
Security is a continuum. One should rationally choose where along it one wants to be. There are defensible, rational reasons to choose to disable SELinux.
Indeed! As long as there are rational reasons for it and that the reason is not "because it is bothersome and troublesome to me, so therefore I always disable it".
For the vast majority of issues with SELinux, it possible to overcome them using the provided tools. Of course, in a few scenarios, that is still not enough or possible. In such cases, I agree, disabling it is the only proper way to do.
But in my experience, such situations are very seldom. It is possible to write pretty good SELinux policies yourself, by using audit2allow and analysing what your program tries to do and why. Doing a good job with a hand crafted SELinux module for your application removes your initial reason why to disable SELinux.
kind regards,
David Sommerseth
On 12/9/2010 1:54 AM, David Sommerseth wrote:
For the vast majority of issues with SELinux, it possible to overcome them using the provided tools.
Of course, but I think you're mistaking "possible" for "practical". Everyone has different incentives and constraints.
Allow me build an analogy with GUI program design. The tools provided with the OS are sufficient for any program to be beautifully designed. We have powerful graphics editors, solid GUI libraries, mature GUI builders, and unprecedentedly powerful means for finding and attracting design talent. Yet, most Linux GUI programs are not as nicely designed as the best counterparts on Windows and OS X.
Why?
Not everyone cares enough to make their GUI program beautiful, especially in a world where a) most of the software is free-as-in-beer; and b) the culture has developed a knee-jerk "if you don't like it go use something else we're volunteers here you ungrateful bastard" reaction to criticism. (I should note here that I'm the primary maintainer of a popular free software package, and I, too have told people to go pound sand when they told me I *need to* do something in order to make my successful project succeed. As in another post in this thread, I'm not disparaging here, just reporting.)
On Windows and OS X, the incentives are different. More software costs money, and among the ways to convince people to pay money for software when there are free alternatives, one way is to make the software more beautiful, and another is to make it easier to use.
Now let's apply that same thinking to SELinux.
First, not all open source projects have the proper incentives to support SELinux. One reason might be that the project started on one of the BSDs and its primary maintainers still use that platform. Their community may be uninterested in providing patches, and they're unlikely to write software that doesn't benefit them in some way.
Then you have the packagers. Those packages not made by people trying to get the package into the Fedora or RHEL official repositories aren't required to support SELinux, so they may choose not to if they don't themselves use SELinux.
Next there are those who just wish to install and use the software. They may not wish to dig into the package to fix SELinux problems any more than you see Joe Shellprompt fixing any of the many other other common problems you find constantly kicked back upstream through complaints in bug trackers and on mailing lists.
That takes us full circle, no one has fixed the issue, and without a sufficient change in the set of user incentives for that package, the cycle will repeat.
Warren Young wrote:
On 12/9/2010 1:54 AM, David Sommerseth wrote:
For the vast majority of issues with SELinux, it possible to overcome them using the provided tools.
Of course, but I think you're mistaking "possible" for "practical". Everyone has different incentives and constraints.
Allow me build an analogy with GUI program design. The tools provided with the OS are sufficient for any program to be beautifully designed. We have powerful graphics editors, solid GUI libraries, mature GUI builders, and unprecedentedly powerful means for finding and attracting design talent. Yet, most Linux GUI programs are not as nicely designed as the best counterparts on Windows and OS X.
Why?
Well, because what most people see, or buy, is WinDoze, so that's where the money is.
On Windows and OS X, the incentives are different. More software costs money, and among the ways to convince people to pay money for software when there are free alternatives, one way is to make the software more beautiful, and another is to make it easier to use.
Also, Apple dictates style; to a lesser degree, so does M$. There's no dictated style guide for Linux.
Now let's apply that same thinking to SELinux.
First, not all open source projects have the proper incentives to support SELinux. One reason might be that the project started on one of
<snip>
Then you have the packagers. Those packages not made by people trying
<snip>
Next there are those who just wish to install and use the software. They may not wish to dig into the package to fix SELinux problems any more than you see Joe Shellprompt fixing any of the many other other common problems you find constantly kicked back upstream through complaints in bug trackers and on mailing lists.
Here's the big one. I've got enough to do without adding selinux on top of the mix. As I said, on almost all our boxen, it's disabled. <snip> mark
On 12/9/2010 2:05 PM, m.roth@5-cent.us wrote:
Also, Apple dictates style; to a lesser degree, so does M$. There's no dictated style guide for Linux.
That's outdated thinking. Apple's acquired some infamy among its fanboy base for violating their old style guidelines, which AFAIR were last updated back in the OS 9 days. OS X followed these rules early on, but probably more out of inertia than requirement from the top. These days, Apple's UI design changes regularly.
The website -> widget -> mobile app progression accelerated this trend. Apple's users have come to accept that each app can be a world unto itself.
I'd accept an argument that Apple dictates fashion, in the same sort of way Vogue or GQ does. As with any fashion, it changes with the seasons.
Another argument I'd accept is that Apple has /taste/. They have it in greater degree than all but a few of their competitors, but it should be realized that it is also changeable.
Observe Apple's nadir while The Steve was exiled. 40^W12 years of wandering in the Silicon Valley desert later, he returned, and Apple's design aesthetic improved greatly. Not up from zero, mind; the famous Jony Ive was at Apple before the return of The Steve. When Steve leaves again, Apple's sense of taste won't disappear, as it did not before, but it will change again.
To drag this back on topic, it's true that a Red Hat or Ubuntu could decide to become more draconian about this, and start refusing to include apps in their distro that violate some arbitrary set of style rules. They're in a better position to enforce this than either Apple or Microsoft, since most of the software the average Linux user uses comes with the distro than comes with a typical Windows or Mac box.
I believe there are efforts toward this, but a lot of the basics are still being overlooked: Enter doesn't always select the default action in a dialog box, there's still disagreement on the "quit program" keyboard shortcut, we still have at least 3 different clipboard-like mechanisms that don't interoperate, etc.
On Thu, 9 Dec 2010, Warren Young wrote:
On 12/9/2010 2:05 PM, m.roth@5-cent.us wrote:
Also, Apple dictates style; to a lesser degree, so does M$. There's no dictated style guide for Linux.
That's outdated thinking. Apple's acquired some infamy among its fanboy
How about this long since OT thread under this Subject be permitted to die ?
Clearly you all like to hear yourselves talk wayyyy too much
-- Russ herrold
On Tuesday, December 07, 2010 06:29:44 pm Les Mikesell wrote:
I think you've missed the point that 'all that stuff' (being traditional unix security mechanisms) are not all that insecure. It is only when you get them wrong that you need to fall back on selinux as a safety net. And if you can't get the simple version right, how can you hope to do it right with something wildly more complicated?
Alright, pray tell how I, a desktop Linux user, can, without VM's and without having to switch users, protect my files from a PDF attack through Adobe Reader? Or a surf-by web infection (NoScript can help; NoScript is also a pain)? Or a flash bug? Or any other exploit an attacker will try to use (and the metasploit framework, among others, makes it trivial to set up these) that doesn't require a root exploit to drop stuff in your .bashrc?
Real world: AJAX, Flash, and Java applets are required for many corporate web sites. They are also required for online banking and other online SaaS applications, including cloud applications. PDF fill-in forms are required in many cases as well. When one of those are compromised (not if, when), how will standard user-based protections help you in a way that doesn't require highly inconvenient solutions like switching users or running 'dangerous' apps in a VM?
(yes, I run plenty of servers, and I have been a VMware user for a very long time. But the desktop security use case often gets short shrift, and thus I raise that banner, being that I have been a desktop Linux user for 13+ years)
-----Original Message----- From: Lamar Owen lowen@pari.edu Reply-To: CentOS mailing list centos@centos.org Date: Wed, 8 Dec 2010 15:21:36 +0000 To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] SELinux - way of the future or good idea but !!!
Alright, pray tell how I, a desktop Linux user, can, without VM's and without having to switch users, protect my files from a PDF attack through Adobe Reader?
Backups.
On Wednesday, December 08, 2010 10:28:38 am L A Hurst wrote:
From: Lamar Owen lowen@pari.edu
Alright, pray tell how I, a desktop Linux user, can, without VM's and without having to switch users, protect my files from a PDF attack through Adobe Reader?
Backups.
I looked in vain for a smiley, and found none.....
Backups aren't going to protect from a PDF exploit or web bug *reading* possibly sensitive data and sending it to an identity thief. This attack vector is becoming rather common on other OS's, and I wouldn't be surprised if it became more common on Linux as Linux gets more rich SaaS client support.
And unless I'm obsessive with watching my rsync logs (which, actually, I am) I'm not going to see a modified file, either, until I need it, which for some files might be past the retention time for even an annual backup.
On 12/8/2010 9:21 AM, Lamar Owen wrote:
On Tuesday, December 07, 2010 06:29:44 pm Les Mikesell wrote:
I think you've missed the point that 'all that stuff' (being traditional unix security mechanisms) are not all that insecure. It is only when you get them wrong that you need to fall back on selinux as a safety net. And if you can't get the simple version right, how can you hope to do it right with something wildly more complicated?
Alright, pray tell how I, a desktop Linux user, can, without VM's and without having to switch users, protect my files from a PDF attack through Adobe Reader?
Don't run software you don't trust. Keep the software you run up to date. Don't open files you don't trust.
Or a surf-by web infection (NoScript can help; NoScript is also a pain)?
Don't visit web sites you don't trust with browsers that auto-execute stuff.
But the desktop security use case often gets short shrift, and thus I raise that banner, being that I have been a desktop Linux user for 13+ years)
Does the default configuration cover the cases you present? Or are you suggesting that every user needs the equivalent of a 4 day/$3K training course to be able to secure their linux distribution?
On 12/08/2010 10:39 AM, Les Mikesell wrote:
Don't run software you don't trust. Keep the software you run up to date. Don't open files you don't trust.
Agree here. We have very few issues at my company, because we stress the issue of thinking before you click, especially when it comes to desktop users. If you think about something before you just automatically do it, it often avoids a problem to begin with.
This applies to any desktop user on any desktop OS. Think before you open something, think before you do something. If you're not sure who sent it, or you don't trust it, or you don't recognize where it's from, then don't open it or consult IT to check it out.
The best and first security is and always will be the physical layer, after that, put some thought into, or teach desktop users to put thought into their actions before they or you actually do it.
Regards, Max
On Wednesday, December 08, 2010 10:39:50 am Les Mikesell wrote:
On 12/8/2010 9:21 AM, Lamar Owen wrote:
Alright, pray tell how I, a desktop Linux user, can, without VM's and without having to switch users, protect my files from a PDF attack through Adobe Reader?
Don't run software you don't trust. Keep the software you run up to date. Don't open files you don't trust.
That has nothing to do with user-id based security, Les. And you're intelligent enough to know that.
You cannot trust any file or software 100%; to trust 100% any file or software over which you don't have 100% control is foolhardy. The OS needs to be able to execute untrusted software in a safe fashion in order to be usable in this day and age, especially with SaaS and cloud computing becoming more and more prevalent. We're not in the 70's or 80's any more; we need working controls that allow untrusted software to be run safely, even if the user running that software is root. Sorry, that's just a simple fact of life in this connected age. Of course, you then need to trust your OS, but the fact that you run the OS is strong prima facie evidence that you trust it at least to a degree (this is of course why I run Linux; I trust it more than the others).
Or a surf-by web infection (NoScript can help; NoScript is also a pain)?
Don't visit web sites you don't trust with browsers that auto-execute stuff.
Visit Linuxtoday.com and go to one of the linked articles; let your cursor roll over a double-underlined word. What happens? What could happen? What about web caches in between? Or rooted cisco routers sending your traffic to and from a WCCP transparent webcache that poisons the stream, does MITM SSL funniness, or worse.
Or a BPG AS hijack such as what was done back in April, that causes your traffic, without your knowledge or awareness, to traverse an autonomous system under potentially nefarious control (can happen, thanks to the nature of BGP)? How do you know for a fact that your packets to and from that trusted website are not filtered, munged, and otherwise changed along the way? Can you trust SSL to not be vulnerable to MITM attacks?
You cannot trust any website 100% (no, you cannot trust 100% *any* website that you don't personally have full control of its software, as well as any and all caches/redirectors/accelerators/routers/switches/AS's in between). The only way to be 100% sure is to not visit any websites at all, ever, period. Wouldn't it easier to apply mandatory access controls to the web browser and allow untrusted content to be rendered safely?
But the desktop security use case often gets short shrift, and thus I raise that banner, being that I have been a desktop Linux user for 13+ years)
Does the default configuration cover the cases you present?
I seriously doubt that it does; I would like to see it cover those cases, even if that means me doing my own legwork and codework.
Or are you suggesting that every user needs the equivalent of a 4 day/$3K training course to be able to secure their linux distribution?
No; what I'm suggesting is that the experts out there that have the corner cases (and the time and inclination to help) try it, at least in testing, and help out an open source effort, the fruits of which they're enjoying, in the case of CentOS, for free, instead of being time-consuming gadflies. I plan to spend some time over the holidays in some autodidactic exercises on this subject; the cost will be minimal, and I'll be the better admin for it. And I'll have a safer system on which to run untrusted software with less risk.
There are many things that need improvement; making a 'this is the way my system runs normally; create a module that won't break when I update things (and define what 'won't break' means)' module builder (for all I know, one may exist already, and audit2allow in conjunction with permissive mode does part of this for you). Not breaking a working system is important to some; failing safe (I'd rather it fail closed than open; YMMV) is also important to others, depending upon the use case of the system.
But the developers of the system cannot possibly nor reasonably be expected to know all the corner cases that people seem overly concerned with (any third party app is by definition a corner case relative to the OS as shipped). They have to have bug reports and help in finding these cases. Simply saying 'I fixed it by turning it off, and, no I don't have time to send you a bug report, you just have to guess what went wrong because I'm not turning it back on until you fix your bug' is just unproductive.
If you want to disable SELinux, then of course by all means go ahead; the risk is all yours. The problem I and others have with the attitude of then making that the default advice sent to the list is that it doesn't help fix the underlying issues, and since the upstream does in fact ship SELinux on by default it is more useful in the default case to try to help fix the actual problem instead of griping about it being junk.
If you prefer to not provide useful information, well, that is of course your right. But that doesn't change my opinion that 'Disable SELinux, do it the Old Unix Way and all will be well' as default advice is useless, and does not help make the default CentOS experience any better.
On 12/8/2010 11:02 AM, Lamar Owen wrote:
On Wednesday, December 08, 2010 10:39:50 am Les Mikesell wrote:
On 12/8/2010 9:21 AM, Lamar Owen wrote:
Alright, pray tell how I, a desktop Linux user, can, without VM's and without having to switch users, protect my files from a PDF attack through Adobe Reader?
Don't run software you don't trust. Keep the software you run up to date. Don't open files you don't trust.
That has nothing to do with user-id based security, Les. And you're intelligent enough to know that.
But your question was what to do if you choose to ignore the simple and available tools - things available and well understood on many platforms.
On Wednesday, December 08, 2010 12:17:40 pm Les Mikesell wrote:
But your question was what to do if you choose to ignore the simple and available tools - things available and well understood on many platforms.
VM = complex. Not to mention proprietary (for all but KVM) and resource-wasteful. Switch User = inconvenient to the extreme, and disruptive of normal workflow.
I've done both, and neither are workable solutions for the majority of users, especially on the desktop. Both are more complex than SELinux *could* be, with some effort.
SELinux is available for every major Linux distribution (including Ubuntu). It's on by default in RHEL/Fedora and most derivatives. And there's the TrustedBSD project's SEBSD port.
Sounds like a budding standard to me, and something worth learning. Time to expand your horizons, not put your head in the sand.
On 12/8/2010 11:38 AM, Lamar Owen wrote:
But your question was what to do if you choose to ignore the simple and available tools - things available and well understood on many platforms.
VM = complex. Not to mention proprietary (for all but KVM) and resource-wasteful. Switch User = inconvenient to the extreme, and disruptive of normal workflow.
I've done both, and neither are workable solutions for the majority of users, especially on the desktop. Both are more complex than SELinux *could* be, with some effort.
*And* standards for the locations every application is permitted to access.
Sounds like a budding standard to me, and something worth learning.
Standards committees have their ways of breaking all previous existing implementations with their final decrees. Let me know when they are finished.
On Wednesday, December 08, 2010 01:02:10 pm Les Mikesell wrote:
Standards committees have their ways of breaking all previous existing implementations with their final decrees. Let me know when they are finished.
Standards committees are never finished.
Linux is not standardized, either; in the case of CentOS, SELinux is a de facto standard as it's in the default install set. Linux != posix.
The inertia of the installed set means what you learn now will still be usable in the future. Much like with Linux itself.
On 12/8/2010 12:19 PM, Lamar Owen wrote:
Standards committees have their ways of breaking all previous existing implementations with their final decrees. Let me know when they are finished.
Standards committees are never finished.
Linux is not standardized, either; in the case of CentOS, SELinux is a de facto standard as it's in the default install set. Linux != posix.
The inertia of the installed set means what you learn now will still be usable in the future. Much like with Linux itself.
But how much of what you spend your time learning do you want to be dedicated and restricted to a single platform? A question that is also going to apply to all 3rd party developers. I'd much rather have developers focusing on eliminating buffer overflows and the kinds of things that cause vulnerabilities in the first place than how best to survive them on one single target platform.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/08/2010 10:21 AM, Lamar Owen wrote:
On Tuesday, December 07, 2010 06:29:44 pm Les Mikesell wrote:
I think you've missed the point that 'all that stuff' (being traditional unix security mechanisms) are not all that insecure. It is only when you get them wrong that you need to fall back on selinux as a safety net. And if you can't get the simple version right, how can you hope to do it right with something wildly more complicated?
Alright, pray tell how I, a desktop Linux user, can, without VM's and without having to switch users, protect my files from a PDF attack through Adobe Reader? Or a surf-by web infection (NoScript can help; NoScript is also a pain)? Or a flash bug? Or any other exploit an attacker will try to use (and the metasploit framework, among others, makes it trivial to set up these) that doesn't require a root exploit to drop stuff in your .bashrc?
Real world: AJAX, Flash, and Java applets are required for many corporate web sites. They are also required for online banking and other online SaaS applications, including cloud applications. PDF fill-in forms are required in many cases as well. When one of those are compromised (not if, when), how will standard user-based protections help you in a way that doesn't require highly inconvenient solutions like switching users or running 'dangerous' apps in a VM?
(yes, I run plenty of servers, and I have been a VMware user for a very long time. But the desktop security use case often gets short shrift, and thus I raise that banner, being that I have been a desktop Linux user for 13+ years) _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Sandbox -X might help solve some of these problems. Available in RHEL6
http://danwalsh.livejournal.com/31146.html?thread=212906
http://video.linuxfoundation.org/video/1565
On Wednesday, December 08, 2010 01:47:07 pm Daniel J Walsh wrote:
Sandbox -X might help solve some of these problems. Available in RHEL6
Looks interesting, Dan. Thanks much. And thanks much for the sometimes thankless work of trying to make the power of SELinux more easily accessible.
On 12/8/2010 8:21 AM, Lamar Owen wrote:
On Tuesday, December 07, 2010 06:29:44 pm Les Mikesell wrote:
And if you can't get the simple version right, how can you hope to do it right with something wildly more complicated?
Alright, pray tell how I, a desktop Linux user,...
Let's not drag the desktop user into this discussion, too.
Long experience has shown that when Joe User tries to do Thing X and is prevented, then a popup appears that in effect says "run this command to make this popup go away and allow Thing X to happen", THEY WILL RUN THE COMMAND. It's so reliable an effect that you could make a killing if any bookie were stupid enough to let you bet on it.
I have a one-word reply pre-prepared for anyone who disagrees: botnet.
Please, let's keep this thread centered on professionally-managed servers, the focus of CentOS, and thus hopefully this list. There is at least hope in that world that something like SELinux could actually be applied successfully.
On Wednesday, December 08, 2010 05:11:23 pm Warren Young wrote:
Let's not drag the desktop user into this discussion, too.
Why not? Are there no CentOS desktop users out there? Are the needs of the desktop just to be ignored? I support desktop Linux users who are not power users; works great for them. They're thrilled to not have viruses.
Long experience has shown that when Joe User tries to do Thing X and is prevented, then a popup appears that in effect says "run this command to make this popup go away and allow Thing X to happen", THEY WILL RUN THE COMMAND. It's so reliable an effect that you could make a killing if any bookie were stupid enough to let you bet on it.
Exactly. That is precisely why you want controls to restrict what some random program can do, and thus remove the danger. In my three teenage childrens' vernacular, 'Well, duh!'
Please, let's keep this thread centered on professionally-managed servers, the focus of CentOS, and thus hopefully this list.
Who says that's the focus? While I'm sure the majority of CentOS installs are for servers, the CentOS desktop does exist. I know I have plenty of CentOS servers; I also have Linux desktops of more than one distribution scattered all over.
On Thursday, December 09, 2010 06:55 AM, Lamar Owen wrote:
On Wednesday, December 08, 2010 05:11:23 pm Warren Young wrote:
Let's not drag the desktop user into this discussion, too.
Why not? Are there no CentOS desktop users out there? Are the needs of the desktop just to be ignored? I support desktop Linux users who are not power users; works great for them. They're thrilled to not have viruses.
+1
I possibly would have had Centos desktops strewn all over the school if it had met certain needs in a trial two years ago.
Long experience has shown that when Joe User tries to do Thing X and is prevented, then a popup appears that in effect says "run this command to make this popup go away and allow Thing X to happen", THEY WILL RUN THE COMMAND. It's so reliable an effect that you could make a killing if any bookie were stupid enough to let you bet on it.
Exactly. That is precisely why you want controls to restrict what some random program can do, and thus remove the danger. In my three teenage childrens' vernacular, 'Well, duh!'
Please, let's keep this thread centered on professionally-managed servers, the focus of CentOS, and thus hopefully this list.
Who says that's the focus? While I'm sure the majority of CentOS installs are for servers, the CentOS desktop does exist. I know I have plenty of CentOS servers; I also have Linux desktops of more than one distribution scattered all over.
It is kind of true that the desktop is a bit neglected by Redhat in comparison to what it does for the server. But whatever. SELinux for the desktop is the same kind of challenge as it is for third-party applications.
On 12/8/2010 3:55 PM, Lamar Owen wrote:
On Wednesday, December 08, 2010 05:11:23 pm Warren Young wrote:
Let's not drag the desktop user into this discussion, too.
Why not?
I thought my reason was clear, but apparently not. You talk the talk of security, but I guess we hang in different security circles and so don't recognize the same shorthand. Allow me to expand.
The reason I don't want to go off into a discussion of SELinux on the desktop is that I believe SELinux -- as shipped in current versions of CentOS -- will fail to stop 99% of the problems you talk about, purely due to the nature of 99% of desktop users.
Those in that vast majority blindly click on things that pop up and stop them from doing what they wanted to do. If a popup message gives a way to make the popup stop appearing, these people will, almost without fail, do that, no matter how well-intentioned or helpful the message, or how inadvisable disabling it is.
These people do not especially enjoy computers -- many actually hate them -- and so do not wish to understand anything more about what they are doing than is required to complete the immediate task. (You may perhaps have seen the current Windows Phone 7 ads? They're aimed straight at this crowd. I believe this ad campaign will be more effective than any Microsoft has had in years.)
Examples:
- UAC on Windows Vista/7. It's done virtually nothing to stop the malware epidemic. Why? It trains users to click on the "yes I really meant to do that" button, regardless of whether the user actually understands what they have just agreed to.
- Hostageware and fake virus popups on the web. The computer tells them they need to spend $X on something that will free their data or remove a virus they don't have. People fall for this all the time.
- Email scams: bogus unsubscribe links, phishing links, false enticements for illicit material...
- How often have you seen this as prologue to a tale of woe: "Are you sure you want to format your operating system hard drive?" "OK"
- Windows security software popups:
-- Firewall: "Blocked connection to port X." "Unblock"
-- Antimalware: "Updated patterns for the sixth time this month" "Go away." Then next week: "Detected possible virus behavior" "Go away." They're trained by then, y'see.
-- Security update: "Apply" Then next week, bogus security popup while surfing Facebook: "Apply"
- Evil EULAs. Not even a technically competent user wants to read pages and pages of legalese. But the point remains, people agree to things they don't bother to understand because they want to get past the annoying popup so they can do what they started out to do.
I am not disparaging this vast majority, merely reporting observed behavior. We're unlikely to ever change them. Many, in fact, are medically incapable of stopping this behavior; it's been studied, and some people are psychologically compelled to click things whenever they appear. (I suppose it's some form of OCD.)
Bottom line, if the tables were flipped on Microsoft and CentOS were the dominant desktop operating system, I believe it would have the same security problems today as it had before SELinux was available. Maybe not the same as Microsoft currently has, but no different than Linux without SELinux.
I wish I could do more than just offer vague, untestable supposition, but the current Linux user base is too small and technically competent to draw any real conclusions about how effective SELinux is at stopping the problems the normals get bit by. It's my experience that the technically competent desktop user rarely needs much in the way of security apparatus. Experience, attitude, and talent allow us to avoid problems most of the time, so the safety net rarely gets tested.
It is possible SELinux would help if seagent didn't exist and didn't show popups. Then the vast majority would simply be frustrated, unable to do what they want, and unlikely find a workaround. Some will manage to dredge up the fix with The Google and blindly type it into a Terminal window, but even that minor impediment would be enough to stop a lot of general users cold. In that case, maybe you have a valid point. Then again, many Windows users disable UAC, so there's no reason to believe that subset wouldn't disable SELinux if CentOS were dominant instead.
To go much deeper, you get into discussions of how (or whether) CentOS should change to prevent these things, but change is driven from upstream and won't happen for years anyway if past is prologue, so again we have a good reason to stop this subthread right here.
Daniel J Walsh wrote:
I wrote this paper to try to explain what SELinux tends to complain about.
http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/selinux_four_t...
I am having difficulty with the pdf file - both adobe and kpdf have problems with the pages with screen shots - any chance of a fix? Paper is well writen and sheds light on the SElinux methodology. TIA - Rob
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkz+XQsACgkQrlYvE4MpobNrgACfZduLdW/ISac6otm8SRO+c4Za S0QAn3l00KRGtNmnaVAy4cFpL/jjrwuz =7ega -----END PGP SIGNATURE----- _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Rob Kampen wrote:
Daniel J Walsh wrote:
I wrote this paper to try to explain what SELinux tends to complain about.
http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/selinux_four_t...
I am having difficulty with the pdf file - both adobe and kpdf have problems with the pages with screen shots - any chance of a fix? Paper is well writen and sheds light on the SElinux methodology. TIA - Rob
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkz+XQsACgkQrlYvE4MpobNrgACfZduLdW/ISac6otm8SRO+c4Za S0QAn3l00KRGtNmnaVAy4cFpL/jjrwuz =7ega -----END PGP SIGNATURE----- _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi,
I can open it with KGhostView all pages display properly except that page 7 is (intentionally ?) blank.
ChrisG
On 12/07/2010 05:11 PM, Rob Kampen wrote:
Daniel J Walsh wrote:
I wrote this paper to try to explain what SELinux tends to complain about.
http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/selinux_four_t...
I am having difficulty with the pdf file - both adobe and kpdf have problems with the pages with screen shots - any chance of a fix?
Those pages don't display properly with Adobe Reader (9.4.1) either. The screen shots cover portions of the text. I can do a "select all" and see that something is back there, but the only way to read it is to copy the selected text and paste it into an editor. In the case of Page 6, it appears that the screen shots covering the text there were intended for Page 7, which is blank.
On Thursday, December 09, 2010 12:02:44 am Robert Nichols wrote:
On 12/07/2010 05:11 PM, Rob Kampen wrote:
Daniel J Walsh wrote: http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/selinux_four_t...
I am having difficulty with the pdf file - both adobe and kpdf have problems with the pages with screen shots - any chance of a fix?
Those pages don't display properly with Adobe Reader (9.4.1) either.
Confirmed with Okular on F14: lowen@localhost:~$ okular --version Qt: 4.7.1 KDE Development Platform: 4.5.3 (KDE 4.5.3) Okular: 0.11.2 lowen@localhost:~$
On Thu, 2010-12-09 at 10:11 -0500, Lamar Owen wrote:
On Thursday, December 09, 2010 12:02:44 am Robert Nichols wrote:
On 12/07/2010 05:11 PM, Rob Kampen wrote:
Daniel J Walsh wrote: http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/selinux_four_t... I am having difficulty with the pdf file - both adobe and kpdf have problems with the pages with screen shots - any chance of a fix?
Those pages don't display properly with Adobe Reader (9.4.1) either.
Confirmed with Okular on F14: lowen@localhost:~$ okular --version Qt: 4.7.1 KDE Development Platform: 4.5.3 (KDE 4.5.3) Okular: 0.11.2 lowen@localhost:~$
This file loads perfectly for me.
openSUSE 11.3 / GNOME 2.30 / Firefox 3.6.12 / Acroread 9.4.0
Hello Jerry,
On Thu, 2010-12-02 at 15:34 -0800, Jerry Franz wrote:
And in an exact example of this, today I needed to update some WordPress (WP) installations. Only, for "some reason" the FTP based autoupdater didn't work today.
Do you feel comfortable letting a web application update itself using FTP or even SSH credentials?
http://wordpress.org/support/topic/filesystem-credentials-very-bad-practice-...
https://bugzilla.redhat.com/show_bug.cgi?id=659294
The patch shown in http://core.trac.wordpress.org/changeset/16625
prompted me to try a
$ grep -r "=\ %s"" *
in the web root of a WordPress installation. The matches are a bunch of possible SQL injections. Haven't checked the actual code paths, but note how all these strings are unescaped and potentially allow the addition of extra statements using ';'.
Regards, Leonard.
On Tue, 2010-12-21 at 13:44 +0100, Leonard den Ottolander wrote:
The patch shown in http://core.trac.wordpress.org/changeset/16625
prompted me to try a
$ grep -r "=\ %s"" *
in the web root of a WordPress installation. The matches are a bunch of possible SQL injections. Haven't checked the actual code paths,
This turned out to a wild goose chase: For all matches the substituted strings are being quoted via wpdb->prepare().
Regard, Leonard.
On Sat, Nov 27, 2010 at 10:58:00AM +1100, Alison wrote:
Hi,
total newbie on CentOS. Just firing up an install of 5.5 on a development webserver. Installed Webmin, Awstats, PHPMyAdmin and Drupal successfully. Yet to work on Sendmail and Samba. SELinux in enforcing mode, reporting "SELinux preventing ifconfig (ifconfig_t) "read write" to /var/webminsessiondb.pag (var_t)".
There is a reason that control panels are effectively unsupported; you just hit on one of those reasons. Although I must admit I don't fully grasp why webmin is referencing ifconfig_t.
Googled the error message without real success in finding fix - bug reports showing. Question is whether worth pursuing as SELinux is the way of the future. Or is SELinux a good idea that never really made it's way into the sun. Thoughts please.
There are only a small number of corner cases in which SElinux is not appropriate; for all other cases it should be enabled.
It exists for a reason and is shipped fully enabled for a reason. Being able to limit access based on contexts and roles is an incredibly powerful tool which greatly improves the security of your server and the integrity of your data.
Following is a list of very useful SElinux resources.
http://wiki.centos.org/HowTos/SELinux http://wiki.centos.org/TipsAndTricks/SelinuxBooleans http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/ http://fedorasolved.org/security-solutions/selinux-module-building http://centoshelp.org/security/selinux-common-commands-troubleshooting
Some quality time with these resources will allow you to correct the SElinux exception you listed above and also give you a much better understanding of SElinux as a whole.
John
-
Adam Tauno Williams -
Alison -
Athmane Madjoudj -
Benjamin Franz -
Bob McConnell -
Brunner, Brian T. -
Chris Geldenhuis -
Christopher Chan -
cpolish＠surewest.net -
Daniel J Walsh -
David Sommerseth -
Eero Volotinen -
Geoff Galitz -
Jerry Franz
-
John R Pierce -
John R. Dennison -
Jorge Fábregas -
L A Hurst -
Lamar Owen -
Leonard den Ottolander -
Les Mikesell -
m.roth＠5-cent.us -
Marko Vojinovic -
Max Hetrick -
Ned Slider -
Nico Kadel-Garcia -
Nicolas Ross -
Patrick Lists -
Paul Heinlein -
Paul Johnson -
R P Herrold -
Ralph Angenendt -
Rob Kampen -
Robert Nichols -
Scott Robbins -
Stephen Harris -
Steve Clark -
Tom H -
Warren Young -
William Warren