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?
In reality, I am not at all sure that a quantum leap in complexity adds to security at all. Any proper use of old-school group permissions can give as finely-grained a security policy as you would like. The time spent running SELinux in permissive mode to configure could better be spent looking for holes in the operating system, or helping patch the many bugs that the speedy Linux development schedule lets through:
http://lwn.net/Articles/409954/
And then we could have real security, and not a false sense of security generated by heavy-sounding phrases like "mandatory access controls." :-)
On Sunday 28 November 2010 22:40:41 brett mm wrote:
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?
In reality, I am not at all sure that a quantum leap in complexity adds to security at all. Any proper use of old-school group permissions can give as finely-grained a security policy as you would like.
No, you're wrong --- SELinux exists precisely because the old-school permissions system is *not* fine-grained enough. That's why SELinux was actually invented, to introduce a more fine-grained control over access.
I am lazy to search now, but I remember seeing a couple of typical counter- examples, where usual permissions system is completely incapable of implementing the level of access control that SELinux gives you. If you do a clever google search I am sure you can find some examples of this.
HTH, :-) Marko
On Sun, 2010-11-28 at 23:42 +0000, Marko Vojinovic wrote:
On Sunday 28 November 2010 22:40:41 brett mm wrote:
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?
In reality, I am not at all sure that a quantum leap in complexity adds to security at all. Any proper use of old-school group permissions can give as finely-grained a security policy as you would like.
No, you're wrong --- SELinux exists precisely because the old-school permissions system is *not* fine-grained enough. That's why SELinux was actually invented, to introduce a more fine-grained control over access.
+1
I am lazy to search now, but I remember seeing a couple of typical counter- examples, where usual permissions system is completely incapable of implementing the level of access control that SELinux gives you.
Even if it is *possible*, the traditional UNIX permissions are a serious *PAIN*. If you want two users to have rw- to a file you... create a group of two users??? You end up with a zillion groups - which is pointless and unmaintainable. Thank goodness for ACL support and setfacl/getfacl. While that isn't SELinux the principal is the same - the tools should rise to match the practice, not the practice be mashed into the functionality of inferior tools.
I was a disable-selinux guy because it seemed like a black box. But I saw ke4qqq present at Ohio LINUX on SELinux and now I'm a believer; it doesn't take much effort and SELinux really is understandable. http://www.whitemiceconsulting.com/2010/09/ohio-linuxfest-2010.html SELinux can even generate the required policies for you! It is an impressively well thought out tool and as indispensable as iptables.
Adam Tauno Williams wrote:
On Sun, 2010-11-28 at 23:42 +0000, Marko Vojinovic wrote:
On Sunday 28 November 2010 22:40:41 brett mm wrote:
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
<snip>
In reality, I am not at all sure that a quantum leap in complexity adds to security at all. Any proper use of old-school group permissions can give as finely-grained a security policy as you would like.
No, you're wrong --- SELinux exists precisely because the old-school permissions system is *not* fine-grained enough. That's why SELinux was actually invented, to introduce a more fine-grained control over access.
No, selinux is a *royal* pain. It may be good for a production box that has systems tested to within an inch of their lives, and you go through an approval process... but for anything else, most folks put it into permissive mode. Certainly, we do, given that there are some AVC's I've been trying to figure out for *months*, and still don't know how to fix, or where the files are that it's complaining about; or want to allow this, but not everything, and have no clue how to allow *only* that, etc. <snip>
Even if it is *possible*, the traditional UNIX permissions are a serious *PAIN*. If you want two users to have rw- to a file you... create a group of two users??? You end up with a zillion groups - which is pointless and unmaintainable. Thank goodness for ACL support and
You mean like the std. upstream practice of creating, by default, a new group for EVERY BLOODY USER, and not, by default, dumping them into, say, users? <snip> mark
On 11/29/2010 7:35 AM, Adam Tauno Williams wrote:
Even if it is *possible*, the traditional UNIX permissions are a serious *PAIN*. If you want two users to have rw- to a file you... create a group of two users???
Yes, there is nothing simpler than a group to represent a group of users.
You end up with a zillion groups - which is pointless and unmaintainable. Thank goodness for ACL support and setfacl/getfacl.
So what do you do when you have user-specific ACLs splattered randomly through the filesystem and the members of the cooperating groups change?
On Mon, 29 Nov 2010, Les Mikesell wrote:
On 11/29/2010 7:35 AM, Adam Tauno Williams wrote:
Even if it is *possible*, the traditional UNIX permissions are a serious *PAIN*. If you want two users to have rw- to a file you... create a group of two users???
Yes, there is nothing simpler than a group to represent a group of users.
You end up with a zillion groups - which is pointless and unmaintainable. Thank goodness for ACL support and setfacl/getfacl.
So what do you do when you have user-specific ACLs splattered randomly through the filesystem and the members of the cooperating groups change?
If userA wants to share a file with userB, they use an ACL, or they need root assistance. That's the ad-hoc case, and it works much better using ACLs than using groups. For the planned case you describe, you create a group in your central directory.
It's much the same under windows.
jh
On Nov 29, 2010, at 7:47 AM, Les Mikesell wrote:
On 11/29/2010 7:35 AM, Adam Tauno Williams wrote:
Even if it is *possible*, the traditional UNIX permissions are a serious *PAIN*. If you want two users to have rw- to a file you... create a group of two users???
Yes, there is nothing simpler than a group to represent a group of users.
You end up with a zillion groups - which is pointless and unmaintainable. Thank goodness for ACL support and setfacl/getfacl.
So what do you do when you have user-specific ACLs splattered randomly through the filesystem and the members of the cooperating groups change?
Perhaps consult with Winblows AD admins as I'm sure they deal with this all the time.
MS$ ACLs have been around for a very long time.
- aurf
On Monday, November 29, 2010 11:58 PM, aurfalien@gmail.com wrote:
You end up with a zillion groups - which is pointless and unmaintainable. Thank goodness for ACL support and setfacl/getfacl.
So what do you do when you have user-specific ACLs splattered randomly through the filesystem and the members of the cooperating groups change?
Perhaps consult with Winblows AD admins as I'm sure they deal with this all the time.
MS$ ACLs have been around for a very long time.
Heh. So we have been reduced to asking Windows admins how to implement best current practice.
On 30 November 2010 09:03, Christopher Chan christopher.chan@bradbury.edu.hk wrote:
On Monday, November 29, 2010 11:58 PM, aurfalien@gmail.com wrote:
You end up with a zillion groups - which is pointless and unmaintainable. Thank goodness for ACL support and setfacl/getfacl.
So what do you do when you have user-specific ACLs splattered randomly through the filesystem and the members of the cooperating groups change?
Perhaps consult with Winblows AD admins as I'm sure they deal with this all the time.
MS$ ACLs have been around for a very long time.
Heh. So we have been reduced to asking Windows admins how to implement best current practice.
I wouldn't...
In my experience what you have in most AD environments is a mess...
On Mon, Nov 29, 2010 at 8:35 AM, Adam Tauno Williams awilliam@whitemice.org wrote:
Even if it is *possible*, the traditional UNIX permissions are a serious *PAIN*. If you want two users to have rw- to a file you... create a group of two users??? You end up with a zillion groups - which is pointless and unmaintainable. Thank goodness for ACL support and setfacl/getfacl. While that isn't SELinux the principal is the same - the tools should rise to match the practice, not the practice be mashed into the functionality of inferior tools.
Adding higher functionality means more cost in performance. This is information right down at the file system level, and UNIX ACL's are *cheap* computationally to administer.
If you need more, you can get into netgroups, or NFSv4 ACL's, or the like. But I don't recommend it. It's fairly unusual to wish to grant permissions to only two users, at least in industry. SELinux, well, it's taking the controls out of band in fascinating ways.
I was a disable-selinux guy because it seemed like a black box. But I saw ke4qqq present at Ohio LINUX on SELinux and now I'm a believer; it doesn't take much effort and SELinux really is understandable. http://www.whitemiceconsulting.com/2010/09/ohio-linuxfest-2010.html SELinux can even generate the required policies for you! It is an impressively well thought out tool and as indispensable as iptables.
Which many sites simply do not use, preferring to leave their servers open internally and rely on external firewalls. I'm not saying this is ideal, but it remains a pretty common approach.
On Sunday, November 28, 2010 05:40:41 pm brett mm wrote:
In reality, I am not at all sure that a quantum leap in complexity adds to security at all. Any proper use of old-school group permissions can give as finely-grained a security policy as you would like.
No, it won't.
Suppose I'm running CentOS on a workstation, and have a need to access a corporate webapp written in Flash, read corporate documents in PDF, and use other applications written in Java. So I'm going to be living in my browser for most things corporate.
How can I prevent a compromised PDF from gaining an attacker access to my entire home directory? More to the point, how to I prevent that PDF from gaining WRITE access to files in my home directory (say, .bashrc for instance)?
With SELinux I can set files and whole hierachies to not allow Acrobat Reader access of various types, while still alllowing access to those areas it needs. Voila! Acrobat Reader vulnerabilities and the PDF's that exploit them no longer have any power to exploit my system. Same with Flash, Java, and Firefox itself. If firefox has no need to write into my Documents directory, then I can lock out my Documents directory to firefox (even when it's running with the right uid:gid that would defeat old-school uid:gid based perms) and not worry about a malicious website exploiting a firefox zero-day modifying any of my files in Documents.
Old-school permissions are user and group ID based; mandatory access controls are not. They can be process-based and file-based (and socket-based, too). They give you the ability to make root not able to touch every file, for instance, unless the process has the right security context (even making it possible to put /usr/bin, /bin, /lib, /usr/lib, the kernel, etc, off-limits for overwriting by root unless the controlling process is in the right security context). SELinux controls can prevent botnet worms from opening network ports for listening; or even for outgoing access.
On a stable server, where the configuration is production-ready, it shouldn't be hard to determine a normal security footprint to write policy to; lock down the security contexts and the number of successful exploits will go down.
What needs to improve are the admin tools to make those sorts of decisions easy. While the selinux configuration tool in Fedora (and thus RHEL as it gets the improvements backported) has improved, it can stand more improvement.
Yes, this sort of thing adds a little complexity (like, for instance, when you want to change ssh to listen to a non-default port; you need to remember three configuration steps: 1.) sshd needs to listen there; 2.) iptables needs to allow the incoming; 3.) and selinux policy needs to allow sshd to bind the port for listening. Previous selinux configuration tools didn't make 3.) as easy as it could be; current Fedora tools at least make it as easy as steps 1 and 2.
On the server side, suppose you're running Plone and Moodle together, and have some integration. You'll want to profile the security footprint, write the policy to it, and implement. If the proper selinux procedures are followed it will survive updates and relabels just fine, and when Moodle and Plone exploits are found, they will prevent remote privilege escalation.
Or, in other words: follow the various mailing lists to see what the most common exploits are actually out there in the wild; then analyze those to see if the old-school techniques would prevent them without convoluted and massive groups. In the Plone instance a PDF exploit might even be something to guard against, since Plone content types for automatic insertion of content from various upload forms is supported. Ie, check to see what's happening in the real world of 2010, not the real world of 1980.
On 11/29/2010 10:40 AM, Lamar Owen wrote:
On Sunday, November 28, 2010 05:40:41 pm brett mm wrote:
In reality, I am not at all sure that a quantum leap in complexity adds to security at all. Any proper use of old-school group permissions can give as finely-grained a security policy as you would like.
No, it won't.
Suppose I'm running CentOS on a workstation, and have a need to access a corporate webapp written in Flash, read corporate documents in PDF, and use other applications written in Java. So I'm going to be living in my browser for most things corporate.
How can I prevent a compromised PDF from gaining an attacker access to my entire home directory? More to the point, how to I prevent that PDF from gaining WRITE access to files in my home directory (say, .bashrc for instance)?
If you don't trust your software, run it under a uid that doesn't have write access to anything important - or in a VM or a different machine for that matter. X has no problem displaying programs running with different uids or locations.
On Tuesday, November 30, 2010 02:35 AM, Les Mikesell wrote:
On 11/29/2010 10:40 AM, Lamar Owen wrote:
On Sunday, November 28, 2010 05:40:41 pm brett mm wrote:
In reality, I am not at all sure that a quantum leap in complexity adds to security at all. Any proper use of old-school group permissions can give as finely-grained a security policy as you would like.
No, it won't.
Suppose I'm running CentOS on a workstation, and have a need to access a corporate webapp written in Flash, read corporate documents in PDF, and use other applications written in Java. So I'm going to be living in my browser for most things corporate.
How can I prevent a compromised PDF from gaining an attacker access to my entire home directory? More to the point, how to I prevent that PDF from gaining WRITE access to files in my home directory (say, .bashrc for instance)?
If you don't trust your software, run it under a uid that doesn't have write access to anything important - or in a VM or a different machine for that matter. X has no problem displaying programs running with different uids or locations.
Hurrah! That's it! Just move the problem elsewhere. Oh, you snipped out a bit too much. Write access is not just the problem. Being able to upload and execute is also a problem. Can you say 'bot'?
On 11/29/2010 4:09 PM, Christopher Chan wrote:
In reality, I am not at all sure that a quantum leap in complexity adds to security at all. Any proper use of old-school group permissions can give as finely-grained a security policy as you would like.
No, it won't.
Suppose I'm running CentOS on a workstation, and have a need to access a corporate webapp written in Flash, read corporate documents in PDF, and use other applications written in Java. So I'm going to be living in my browser for most things corporate.
How can I prevent a compromised PDF from gaining an attacker access to my entire home directory? More to the point, how to I prevent that PDF from gaining WRITE access to files in my home directory (say, .bashrc for instance)?
If you don't trust your software, run it under a uid that doesn't have write access to anything important - or in a VM or a different machine for that matter. X has no problem displaying programs running with different uids or locations.
Hurrah! That's it! Just move the problem elsewhere.
Yes, if you are concerned about security of certain files it is indeed a good idea to run software you don't trust elsewhere. And if the problem is not trusting software, why are you putting blind faith in the SELinux code?
Oh, you snipped out a bit too much. Write access is not just the problem. Being able to upload and execute is also a problem. Can you say 'bot'?
You don't need SELinux to mount the space writable by the uid in question with the noexec option.
----- Original Message ----- From: "Les Mikesell" lesmikesell@gmail.com To: centos@centos.org Sent: Tuesday, November 30, 2010 6:19 AM Subject: Re: [CentOS] SELinux - way of the future or good idea but !!!
On 11/29/2010 4:09 PM, Christopher Chan wrote:
If you don't trust your software, run it under a uid that doesn't have write access to anything important - or in a VM or a different machine for that matter. X has no problem displaying programs running with different uids or locations.
Hurrah! That's it! Just move the problem elsewhere.
Yes, if you are concerned about security of certain files it is indeed a good idea to run software you don't trust elsewhere. And if the problem is not trusting software, why are you putting blind faith in the SELinux code?
Oh certainly. That is why there is a separate SELinux user context for apache too. Blind faith in SELinux code? Hey, let's not run anything at all then. SELinux provides an extra layer of security to use against exploits that may go beyond what we can do with the usual posix provisions. I do not see why you have a problem with it.
Oh, you snipped out a bit too much. Write access is not just the problem. Being able to upload and execute is also a problem. Can you say 'bot'?
You don't need SELinux to mount the space writable by the uid in question with the noexec option.
IF that zero day exploit actually uploads to that space only.
On 11/29/10 8:10 PM, Christopher Chan wrote:
Yes, if you are concerned about security of certain files it is indeed a good idea to run software you don't trust elsewhere. And if the problem is not trusting software, why are you putting blind faith in the SELinux code?
Oh certainly. That is why there is a separate SELinux user context for apache too. Blind faith in SELinux code? Hey, let's not run anything at all then. SELinux provides an extra layer of security to use against exploits that may go beyond what we can do with the usual posix provisions. I do not see why you have a problem with it.
Not so much a problem - I'm just saying that you should do the simple things that have always worked first, then add SELinux if you want.
On Monday, November 29, 2010 09:35:44 pm Les Mikesell wrote:
Not so much a problem - I'm just saying that you should do the simple things that have always worked first, then add SELinux if you want.
First, I hope everyone else is enjoying the thread as much as I; I always like to see divergent opinions, especially by those who in other venues have proven their technical mettle, of which this list has plenty. And, while I am more than aware that this is not CentOS-specific, it is directly related to a default CentOS installation, that is, SELinux in enforcing mode with the targeted policy (last I installed C5.5 that was the case).
Now, I want to ask, given the two alternatives: 1.) Set up another uid to run PDF, browser, flash, etc and either switch between them or use some display indirection/ forwarding complexity to not have to switch, or fire up a VMware resoure hog (I do use VMware; firing up a whole 'nother OS in a VM reduces the performance of host apps, no matter how I tune them) and use Unity to make it look seamless....
or
2.) Be able to tell my os 'PDF reader can only do X to these files, and no others. Browser cannot read ~/Documents, and can only write in ~/.mozilla. Flash plugin cannot write anywhere without specific user permission and can only read those files it requires to work.'
As to the trust issue, well, I trust the SELinux code as much as any other code in the Linux kernel, including the uid:gid permissions code. I know in all cases that the code is getting well-qualified eyes looking at it, and, should I want to train myself to look at it in that detail, I can.
There are sever-side equivalent examples, but I am purposely playing the desktop advocate here, so I'll leave those as a reader exercise.
Lamar Owen wrote:
On Monday, November 29, 2010 09:35:44 pm Les Mikesell wrote:
Not so much a problem - I'm just saying that you should do the simple things that have always worked first, then add SELinux if you want.
<snip>
Now, I want to ask, given the two alternatives: 1.) Set up another uid to run PDF, browser, flash, etc and either switch between them or use some display indirection/ forwarding complexity to not have to switch, or fire up a VMware resoure hog (I do use VMware; firing up a whole 'nother OS in a VM reduces the performance of host apps, no matter how I tune them) and use Unity to make it look seamless....
or
2.) Be able to tell my os 'PDF reader can only do X to these files, and no others. Browser cannot read ~/Documents, and can only write in ~/.mozilla. Flash plugin cannot write anywhere without specific user permission and can only read those files it requires to work.'
Gag! And suppose you d/l a pdf, or an html of a manual, or the company holiday party flyer, or the meeting annoucement - the way you describe it, above, I can't look at them. <snip> As I said, the whole arcane policy language, and it being for *everything*... and you've said it's esp. for apache, and most of the AVC's I see that I have problems even figuring out what it's complaining about, have been related to apache and cgi, etc.
Sorry, but I think selinux is a side pathway that leads to an unnavigable swamp. And training folks - you need a number of folks *all* of whom can deal with that swamp.
Unless, of course, you want to be so irreplaceable that they don't want you to ever take a vacation, and are on call 24x7x365.25.
mark, been there without realizing it, done that, WON'T DO IT AGAIN
On Tuesday, November 30, 2010 11:38:24 am m.roth@5-cent.us wrote:
Lamar Owen wrote:
2.) Be able to tell my os 'PDF reader can only do X to these files, and no others. Browser cannot read ~/Documents, and can only write in ~/.mozilla. Flash plugin cannot write anywhere without specific user permission and can only read those files it requires to work.'
Gag! And suppose you d/l a pdf, or an html of a manual, or the company holiday party flyer, or the meeting annoucement - the way you describe it, above, I can't look at them.
Valid point; I'd just want to tune my policy. The biggest lack I see right now is a simple interface to the policy settings, but it is getting better each iteration.
Sorry, but I think selinux is a side pathway that leads to an unnavigable swamp. And training folks - you need a number of folks *all* of whom can deal with that swamp.
You are certainly entitled to your opinion.
Swamps are buildable with ACL's, SELinux contexts, user permissions, and basically any other controls. Well-groomed gardens are also buildable with these tools; at least the tools are available. One should not avoid greenery entirely just because one has seen overgrown yards before.
Unless, of course, you want to be so irreplaceable that they don't want you to ever take a vacation, and are on call 24x7x365.25.
For my own laptop? :-) And why would I want to be on call 365 weeks a year?
No one is ever irreplaceable. Least of all me.
Security concerns should be part and parcel of any application rollout, and it is irresponsible to ignore any of the myraid tools at hand to perform the task.
Lamar Owen wrote:
On Tuesday, November 30, 2010 11:38:24 am m.roth@5-cent.us wrote:
Lamar Owen wrote:
2.) Be able to tell my os 'PDF reader can only do X to these files, and no others. Browser cannot read ~/Documents, and can only write in ~/.mozilla. Flash plugin cannot write anywhere without specific user permission and can only read those files it requires to work.'
Gag! And suppose you d/l a pdf, or an html of a manual, or the company holiday party flyer, or the meeting annoucement - the way you describe it, above, I can't look at them.
Valid point; I'd just want to tune my policy. The biggest lack I see right now is a simple interface to the policy settings, but it is getting better each iteration.
Right - change *local* policy for every iteration.
Sorry, but I think selinux is a side pathway that leads to an unnavigable swamp. And training folks - you need a number of folks
*all* of whom can
deal with that swamp.
You are certainly entitled to your opinion.
Swamps are buildable with ACL's, SELinux contexts, user permissions, and basically any other controls. Well-groomed gardens are also buildable with these tools; at least the tools are available. One should not avoid greenery entirely just because one has seen overgrown yards before.
I'm talking about the real, outside world, *not* my own personal system. And for personal systems, even though it would protect a lot of folks, it would stop them from doing still more... and we're talking about folks who are *NOT* knowledgable.
Unless, of course, you want to be so irreplaceable that they don't want you to ever take a vacation, and are on call 24x7x365.25.
For my own laptop? :-) And why would I want to be on call 365 weeks a year?
As I said, I work in the real world with all this, and you seem to be arguing, based on your own personal experience that those of us in the workplace should do thus-and-so, and we're telling you what it's like in the trenches, and why we don't like selinux. <snip>
mark
On Tuesday, November 30, 2010 01:22:53 pm m.roth@5-cent.us wrote:
Right - change *local* policy for every iteration.
On the servers I would of course put policy into revision control and build it into our customization package (I've built RPM's for a long time). Then consistent contexts can get propagated across the ESX CentOS guests.
And policy doesn't have to be changed for every iteration, any more than ownership or file permissions have to be kept up to date for every iteration.
I'm talking about the real, outside world, *not* my own personal system. ...... As I said, I work in the real world with all this, and you seem to be arguing, based on your own personal experience that those of us in the workplace should do thus-and-so, and we're telling you what it's like in the trenches, and why we don't like selinux.
Well, Mark, I have always been an advocate of 'eating my own dog food' figuratively speaking. If I, the CIO, can't get it to work on my personal system, then it's not likely going to work when deployed to production servers, either. And since I delve into the trenches (fusion splicing fiber when needed, for that matter) nearly daily, fighting the ever present malware, the ever present spam tsunami, and the ever present risk of hacks (filled a /var/log partition one day; server VM template got an update after that to increase the size of that partition), I take a lot more rest when a known and proven security enhancement is working.
Now, I'm not so naive that I'm going to say our systems aren't vulnerable; I'm sure some enterprising soul out there could probably break in, and then we'd have to clean up the mess; cost of doing business. But every reasonable step to increase security is a step I'm willing to take; especially when the cost is small, in my production server farm, with the mix of applications we run. YMMV.
The OP asked " 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."
My opinion, and the opinion of Upstream (judging from the OOB setup), among many other studied opinions here on this list, is that the OP (Alison, I think?) should study SELinux, as it is most definitely going to increase in the future. It's not going away, and falling back on permissive mode as the final operating state is just going ostrich on the problems out there.
I truly do sympathize with your situation; the malicious attackers out there looking for a way in to every system they can get their grubby little paws on will not sympathize, and if the lack of SELinux support creates a hole, they will exploit it. And I've read through some forum postings from you on your issues with SiteMinder; so I understand it's frustrating. I do understand that.
This thread has already, for me at least, futher reinforced the need to better understand the workings of SELinux; the documentation has improved a lot since I last read it, so now is the time to dig back in and see if some improvements have been made. Because, no, it's not as easy as it should be, and, yes it can sometimes break in arcane ways (but so can KDE, or GNOME, or anything else). But it is worth studying, which is the the answer I give to the OP's question.
Lamar Owen wrote:
On Tuesday, November 30, 2010 01:22:53 pm m.roth@5-cent.us wrote:
<snip>
I'm talking about the real, outside world, *not* my own personal system. ...... As I said, I work in the real world with all this, and you seem to be arguing, based on your own personal experience that those of us in the workplace should do thus-and-so, and we're telling you what it's like in the trenches, and why we don't like selinux.
Well, Mark, I have always been an advocate of 'eating my own dog food' figuratively speaking. If I, the CIO, can't get it to work on my personal system, then it's not likely going to work when deployed to production
<snip> Oh, I see: you're the CIO? So you can mandate this. Not having ever been anywhere near a management position, and all of my managers (with three exceptions, one small, and two microscopically small) being at least 3 levels of managment down from VP level, and mostly they have no clue about selinux, if they're not Windows-centric, not where I live.
mark
From: Les Mikesell lesmikesell@gmail.com
why are you putting blind faith in the SELinux code?
Because it comes from the NSA! The backdoor experts... ;P
JD
PS: joking of course, the NSA would never do anything bad...
Hello John,
On Tue, 2010-11-30 at 02:12 -0800, John Doe wrote:
From: Les Mikesell lesmikesell@gmail.com
why are you putting blind faith in the SELinux code?
The SELinux restrictions are a much bigger hurdle to take for a buffer overflow exploit than setting a "safe" uid.
Because it comes from the NSA! The backdoor experts... ;P
PS: joking of course, the NSA would never do anything bad...
This of course was a serious concern by any of the early adopters. It has been discussed in length on various mailing lists. But since the code is available it can and has been audited. Unless of course the Linux developers are collaborating with the NSA to take over your computer and they slipped us a mickey.
Regards, Leonard.
On 30/11/10 10:54 PM, Leonard den Ottolander wrote:
On Tue, 2010-11-30 at 02:12 -0800, John Doe wrote:
Because it comes from the NSA! The backdoor experts... ;P
PS: joking of course, the NSA would never do anything bad...
This of course was a serious concern by any of the early adopters. It has been discussed in length on various mailing lists. But since the code is available it can and has been audited. Unless of course the Linux developers are collaborating with the NSA to take over your computer and they slipped us a mickey.
As you say, it was eventually determined that the NSA did not insert anything dodgy in the code to give them access. They only did two things which caused a certain amount of questioning, to a greater or lesser extent:
1) They only work with Red Hat officially because it is an American company, though the current business model of Red Hat made the partnership far more viable.
2) In spite of many requests, they refused point blank to incorporate encryption in any of the enhancements.
The reason for the second one is pretty obvious, though, they know that SELinux would be (and is) used by non-Americans and they don't want to protect foreign secrets, they want to discover them.
Regards, Ben
Ben McGinnes wrote:
On 30/11/10 10:54 PM, Leonard den Ottolander wrote:
On Tue, 2010-11-30 at 02:12 -0800, John Doe wrote:
<snip>
As you say, it was eventually determined that the NSA did not insert anything dodgy in the code to give them access. They only did two
I dunno, selinux is pretty dodgy....
things which caused a certain amount of questioning, to a greater or lesser extent:
<snip>
- In spite of many requests, they refused point blank to incorporate
encryption in any of the enhancements.
The reason for the second one is pretty obvious, though, they know that SELinux would be (and is) used by non-Americans and they don't want to protect foreign secrets, they want to discover them.
Um, not quite: there *are* export controls on encryption, and even if they wanted it, they couldn't.
mark
On 1/12/10 2:32 AM, m.roth@5-cent.us wrote:
Ben McGinnes wrote:
The reason for the second one is pretty obvious, though, they know that SELinux would be (and is) used by non-Americans and they don't want to protect foreign secrets, they want to discover them.
Um, not quite: there *are* export controls on encryption, and even if they wanted it, they couldn't.
With the crypto that is already included by default in Linux (e.g. OpenSSH, OpenSSL, etc.), US companies are already unable to distribute their products to those few countries left on the list that those export controls apply to (not that that actually stops those countries from obtaining it anyway). You won't find any RHEL service contracts in Syria, Cuba, Iran, North Korea and whichever other countries are on the list (I can't be bothered looking it up).
It's more likely that the NSA reasoning is operational rather than legal. There are already enough suppliers of cryptographic software within the United States to show that compliance with that legislation is still possible. The NSA know that the crypto genie is out of the bottle, they're just not willing to share their own advances. Which makes sense considering what they do, it's not like GCHQ shares its advances with UK firms or the DSD shares theirs with Australian firms.
Regards, Ben
On Tuesday 30 November 2010 11:54:57 Leonard den Ottolander wrote:
why are you putting blind faith in the SELinux code?
Because it comes from the NSA! The backdoor experts... ;P
PS: joking of course, the NSA would never do anything bad...
This of course was a serious concern by any of the early adopters. It has been discussed in length on various mailing lists. But since the code is available it can and has been audited. Unless of course the Linux developers are collaborating with the NSA to take over your computer and they slipped us a mickey.
...bzzzzzt...
WE ARE THE NSA OF BORG. LOWER YOUR FIREWALLS AND SURRENDER YOUR DISKS. WE WILL ASSIMILATE YOUR BIOLOGICAL AND TECHNOLOGICAL DISTINCTIVENESS. YOUR PROCESSORS WILL BE ADAPTED TO SERVE OUR OWN. RESISTANCE IS FUTILE.
...bzzzzzt...
Sorry, couldn't resist... ;-)
Best, :-) Marko
On Tuesday, November 30, 2010 05:12:17 am John Doe wrote:
From: Les Mikesell lesmikesell@gmail.com
why are you putting blind faith in the SELinux code?
Because it comes from the NSA! The backdoor experts... ;P
Also the SCIF experts.
SCIFs are used by people other than intelligence agencies and in areas other than intelligence; HIPAA compliance, for instance. The wikipedia article is a good read.
In other words, SELinux embodies the SCI 'need to know' paradigm in-kernel: the process's uid might have the clearance to access a piece of data, but if it doesn't have a need to access it shouldn't be allowed to access it. And perhaps it can access, but not modify. Perhaps it needs monitoring by other processes in order to access. Etc. SELinux gives the tools to allow the decoupling of 'cleared to know' with 'need to know.'
On 11/29/2010 05:09 PM, Christopher Chan wrote:
Hurrah! That's it! Just move the problem elsewhere. Oh, you snipped out a bit too much. Write access is not just the problem. Being able to upload and execute is also a problem. Can you say 'bot'?
What we've done at my place of employment for a few of these kinds of issues is take a similar approach. We have a VM on a completely isolated network in the DMZ. Folks that need to access Facebook related items VNC to this machine since we have Facebook and other known social media sites blocked because of malware problems.
If/when it gets hosed, we roll a snapshot back to good, or keep a copy of a good know instance, and no one inside the network is harmed since the machine has no internal access. In a case like this, yes, moving the problem elsewhere was a very practical and easy approach to a security issue. Obviously this example is a very specific one, but you shouldn't just automatically dismiss using a VM and moving the problem elsewhere for other practical purposes. It's a very good and practical solution to some security concerns.
This is a bit offtopic from SELinux, but there are folks using this approach successfully to address some of these issues.
Regards, Max
----- Original Message ----- From: "Max Hetrick" maxhetrick@verizon.net To: "CentOS mailing list" centos@centos.org Sent: Tuesday, November 30, 2010 6:51 AM Subject: Re: [CentOS] SELinux - way of the future or good idea but !!!
On 11/29/2010 05:09 PM, Christopher Chan wrote:
Hurrah! That's it! Just move the problem elsewhere. Oh, you snipped out a bit too much. Write access is not just the problem. Being able to upload and execute is also a problem. Can you say 'bot'?
What we've done at my place of employment for a few of these kinds of issues is take a similar approach. We have a VM on a completely isolated network in the DMZ. Folks that need to access Facebook related items VNC to this machine since we have Facebook and other known social media sites blocked because of malware problems.
If/when it gets hosed, we roll a snapshot back to good, or keep a copy of a good know instance, and no one inside the network is harmed since the machine has no internal access. In a case like this, yes, moving the problem elsewhere was a very practical and easy approach to a security issue. Obviously this example is a very specific one, but you shouldn't just automatically dismiss using a VM and moving the problem elsewhere for other practical purposes. It's a very good and practical solution to some security concerns.
Oh certainly. Guess why I run Windows servers in a VM? If it was a Linux box, I don't see why I should not also make use of SELinux even if the installation is running in a VM.
This is a bit offtopic from SELinux, but there are folks using this approach successfully to address some of these issues.
Don't worry, easy to bring back to the topic.
Hello Les,
On Mon, 2010-11-29 at 12:35 -0600, Les Mikesell wrote:
If you don't trust your software, run it under a uid that doesn't have write access to anything important - or in a VM or a different machine for that matter. X has no problem displaying programs running with different uids or locations.
Using a "safe uid" will not stop a buffer overflow from happening and causing a privilege escalation if such an issue exists in the software. SELinux will negate most of the damage by disallowing even the escalated process access to resources it shouldn't touch.
With the ever increasing complexity of software is there any software you trust? I know I don't. Are you running your Flash plugin in Mozilla as a different user than the one you logged into under X? Care to elaborate how to accomplish such a feat? Or can you provide any pointers?
Regards, Leonard.
On Tuesday, November 30, 2010 07:45 PM, Leonard den Ottolander wrote:
Hello Les,
On Mon, 2010-11-29 at 12:35 -0600, Les Mikesell wrote:
If you don't trust your software, run it under a uid that doesn't have write access to anything important - or in a VM or a different machine for that matter. X has no problem displaying programs running with different uids or locations.
Using a "safe uid" will not stop a buffer overflow from happening and causing a privilege escalation if such an issue exists in the software. SELinux will negate most of the damage by disallowing even the escalated process access to resources it shouldn't touch.
With the ever increasing complexity of software is there any software you trust? I know I don't. Are you running your Flash plugin in Mozilla as a different user than the one you logged into under X? Care to elaborate how to accomplish such a feat? Or can you provide any pointers?
Forget it Leonard. He says he has no problem with SELinux but he has strenuously tried to come up with every sort of excuse he can think of to tell others to not bother with it. So it seems to me that he is either trolling or is willing to make himself a soundboard for others to see the need to implement and run SELinux.
Leonard den Ottolander wrote:
With the ever increasing complexity of software is there any software you trust? I know I don't. Are you running your Flash plugin in Mozilla as a different user than the one you logged into under X? Care to elaborate how to accomplish such a feat? Or can you provide any pointers?
That one's easy, don't ever install the plugin, or anything else from Adobe. Second step, set NoScript to block everything and everyone. If any site has content that requires either of those, I will never see it. That's their loss, not mine. If they want me to see it they can make it available via the approved methods.
Bob McConnell N2SPP
On Tuesday, November 30, 2010 04:53:38 pm Bob McConnell wrote:
That one's easy, don't ever install the plugin, or anything else from Adobe. Second step, set NoScript to block everything and everyone. If any site has content that requires either of those, I will never see it. That's their loss, not mine. If they want me to see it they can make it available via the approved methods.
Well, that's the point: there are corporate/enterprise applications written in various scripting languages that you simply have to use if you are that corporation's employee. Whitelisting sites is good; being able to restrict the plugin's access is better. AJAXed applications are becoming the norm, not the exception, and I have seen (and evaluated) applications where the client was in Air, or Flash (that had to have a particular Flash plugin, and the non-Adobe solutions weren't acceptable), or had fillable PDF's, and other interesting things along those lines.
And the number of Java applications that require the Oracle 1.6 JRE are numerous; many won't work with OpenJDK. So you have to have an Oracle JRE. And, yes, those can be a challenge to integrate properly (SELinux or no SELinux). Scalix, for instance, is primarily written in Java (so is OpenXchange, for that matter), but at least it bundles a tested JRE and plays nice with the SELinux targeted policy.
Lamar Owen wrote:
On Tuesday, November 30, 2010 04:53:38 pm Bob McConnell wrote:
That one's easy, don't ever install the plugin, or anything else from Adobe. Second step, set NoScript to block everything and everyone. If any site has content that requires either of those, I will never see it. That's their loss, not mine. If they want me to see it they can make it available via the approved methods.
Well, that's the point: there are corporate/enterprise applications written in various scripting languages that you simply have to use if you are that corporation's employee. Whitelisting sites is good; being able
<snip> On this, I have to agree with Lamar. Last summer - or was it the year before? - when I was job-hunting, I saw one corporate "career" page - maybe Lockheed-Martin? - anyway, they had an idiot flash video of someone talking about their "featured jobs". And a year or two before, I saw a corporate web page (not a consulting firm) that WOULD NOT ALLOW YOU onto the page to fill out an application and offer your resume if you didn't have flash!!!
mark "go find a job in Hollywood"
On Tue, Nov 30, 2010 at 5:23 PM, Lamar Owen lowen@pari.edu wrote:
On Tuesday, November 30, 2010 04:53:38 pm Bob McConnell wrote:
That one's easy, don't ever install the plugin, or anything else from Adobe. Second step, set NoScript to block everything and everyone. If any site has content that requires either of those, I will never see it. That's their loss, not mine. If they want me to see it they can make it available via the approved methods.
Well, that's the point: there are corporate/enterprise applications written in various scripting languages that you simply have to use if you are that corporation's employee. Whitelisting sites is good; being able to restrict the plugin's access is better. AJAXed applications are becoming the norm, not the exception, and I have seen (and evaluated) applications where the client was in Air, or Flash (that had to have a particular Flash plugin, and the non-Adobe solutions weren't acceptable), or had fillable PDF's, and other interesting things along those lines.
And the number of Java applications that require the Oracle 1.6 JRE are numerous; many won't work with OpenJDK. So you have to have an Oracle JRE. And, yes, those can be a challenge to integrate properly (SELinux or no SELinux). Scalix, for instance, is primarily written in Java (so is OpenXchange, for that matter), but at least it bundles a tested JRE and plays nice with the SELinux targeted policy.
No, *THAT* is the sort of reason that I got involved in JPackage packaging of JDK RPM's....
Lamar Owen wrote:
With SELinux I can set files and whole hierachies to not allow Acrobat Reader access of various types, while still alllowing access to those areas it needs. Voila! Acrobat Reader vulnerabilities and the PDF's that exploit them no longer have any power to exploit my system. Same with Flash, Java, and Firefox itself. If firefox has no need to write into my Documents directory, then I can lock out my Documents directory to firefox (even when it's running with the right uid:gid that would defeat old-school uid:gid based perms) and not worry about a malicious website exploiting a firefox zero-day modifying any of my files in Documents.
Your enthusiasm for SELinux seems tied conceptually to a workstation running the set of applications that come with the distribution. Nothing wrong with that.
On Monday, November 29, 2010 11:02:59 pm cpolish@surewest.net wrote:
Your enthusiasm for SELinux seems tied conceptually to a workstation running the set of applications that come with the distribution. Nothing wrong with that.
I have used a Linux as my primary desktop for 13 years; so, yeah, I do sometimes have a desktop slant. I've run Linux servers for that same amount of time; I've seen hacks succeed, and recently I've seen hacks fail thanks to SELinux.
I bring out desktop scenarios simply to bring that out in a sea of server-centric discussions; do that will by default give the sense that I'm desktop-slanted, when I run both, but have quicker desktop paradigms since I use my desktop in more 'critical' ways than I use my servers (things like online banking on the desktop, where data theft is the critical issue). Now my servers are mission-critical for sure; but data theft there wouldn't be quite as directly impacting as data theft on my laptop would be.
Of course, my desktops are Fedora rather than CentOS; although I might switch one to CentOS 6 early next year.
I'll add to the large (often interesting, but large nonetheless) pile of messages in this thread by remarking that even in permissive mode, SELinux can be very useful as an audit tool.
Those AVC messages folks love to hate show deviations from expected behavior. Sometimes those deviations are false positives and require a policy adjustment or relabeling. Sometimes, however, they show in great detail exactly what an exploited vulnerability did (or tried to do): read or replace files, open TCP ports or sockets, create and populate directories.
A while back, someone exploited a vulnerability on a machine in my care. I'd been having trouble getting other apps on that machine to work and play well with SELinux so I had it running in permissive mode. Using the audit logs, I was able to ascertain with a high degree of confidence the extent of the damage -- using information that would have been unavailable but for SELinux.
Of course, the exploit wouldn't have been possible if I'd been running SELinux in enforcing mode... :-)
-
Adam Tauno Williams -
aurfalien＠gmail.com -
Ben McGinnes -
Bob McConnell -
brett mm -
Christopher Chan -
cpolish＠surewest.net -
Jeff Allison -
John Doe -
John Hodrien -
Lamar Owen -
Leonard den Ottolander -
Les Mikesell -
m.roth＠5-cent.us -
Marko Vojinovic -
Max Hetrick -
Nico Kadel-Garcia -
Paul Heinlein