After reading through the various SELinux threads, I really became quite perturbed. I mean, really quite perturbed.
As an IT Director (and the entire IT department, currently), if I were hiring a sysadmin I know for a fact that someone whose first response to a question on why something doesn't work is 'turn it off' would not get a job here.
Neither would a sysadmin with as much cynicism as has been displayed, or an automatic 'it broke things' when something new (and in fact improved) comes along get a job here. Do realize that this list is archived, and that many people who are hiring might use Google to find your name (or mine, for that matter).
No, I would hire someone who would read enough of the friendly manual to know where to look and who to ask to find the fix for the real problem. The real fix is there; thanks to the KMail developers for including a 'mark as important' feature so I can find that message amongst the drivel in that thread easily (well, actually I'll probably just delete everything but the real solution).
It is the lazy sysadmin who just turns things off without an understanding as to why they are turned off; don't give me the 'overworked' line; you had enough time to post here on the brokenness of SELinux, so you had enough time to find the problem's real source. I am not interested in hiring lazy sysadmins, once I get to hiring. Bryan Smith, for all the verbosity he is known for, doesn't seem to be lazy and could likely hold the job; Craig White likewise, among many others here. I won't name all the names to protect the guilty. :-)
The main reason I think sysadmins in general seem to hate SELinux is the 'Mandatory' part of 'Mandatory Access Control' : that is, superuser power is too addictive to get rid of, and SELinux can do away with 'superuser' powers entirely. AND THAT IS A GOOD THING. Yes, it really is. The buffer overflow exploit for those root-running daemons doesn't stand a chance even if it gains root, as long as the selinux policies are set properly.
And, yes, it is possible to set the policies properly; any daemon whose developers feel that it needs to be exempt from such might have a problem running on my servers.
In a nutshell, SELinux is on and enabled everywhere here; I can't seem to find any measureable speed difference between SELinux targeted, permissive or off; it is unobtrusive in my experience, and it does indeed help protect internet-facing systems from unknown buffer overflows. This is a good thing, and I am convinced that the minor inconvenience of learning a new security tool's configuration is a great tradeoff; especially when the alternative is a compromised system. As there is no such thing as a 100% secure system, anything that improves security but, when properly configured, doesn't impact usability is a BIG WIN in a my book, and probably in many other IT Directors' books too.
I have been running Red Hat Linux on internet-facing servers for quite a while, now, and in my opinion and experience, SELinux is the best thing to happen to Linux since 0.13 was released. It's about time the antiquated default Unix permissions system was overhauled. Yes, it requires study, thought, and care. I would expect nothing less of any sysadmins who would work under me.
Also, as one poster wrote, SELinux is NOT a *service* but is indeed the Bully Boss of the system. This is also a good thing for internet-facing servers to have; how is the machine supposed to know that the Real Root has logged in, and that that process with euid 0 really was started by the Real Root?
The Real Root should take the time to configure in to the policies those things the Real Root would normally do (you know, things like backups and the like, along with other normal activities), but then block those actions that the Real Root would not do (like install a rootkit; yes, a properly configured SELinux can prevent installation of a rootkit on your machine even if it gets 'rooted'). The power of the properly configured Mandatory Access Control system (The Bully Boss) is completely in the control of the Real Root, but untouchable by those Fake Roots who wish to do your system harm.
This is again a good thing, and one I would think Diligent Sysadmins would be falling over themselves trying to learn and deploy.
Lamar Owen lowen@pari.edu wrote:
As an IT Director (and the entire IT department,
currently),
if I were hiring a sysadmin I know for a fact that someone whose first response to a question on why something doesn't work is 'turn it off' would not get a job here.
Don't read too much on what other people say on a list -- including the person I'm sure you're referencing here (It's actually not me for once! Whew! ;-). Sometimes people just don't like things, and their opinions would come off much better in person than e-mail. I _always_ think that, even when I completely disagree with someone.
As far as "one-upmanship," in just the last 2 months, I have catelogued no less than 21 separate incidents of "one-upmanship" (yes, I was part of a number of them -- but I was also not part of a _majority_ of them -- especially when I wasn't posting for awhile), and the total is by _more_ than 1 dozen different people.
Anytime you get enough intelligent people in a group, you're going to have differences and varying opinions. Trying to label someone based on them in e-mail is rather poor, so no one should try. Even in my own, local LUG, people vary in e-mail from in-person, but at least we see each other in-person. God knows at a place of work, I go to someone's office (if they are local) or pick up the phone and/or use remote meeting capabilities (if they are not) to explain something.
E-mail _sucks_ as a medium for explaining ideas clearly. ;-> It's only good for log files and cut'n pasting things. ;->
That's why question/summary-only mailing lists like Sun Managers and Linux Managers are best when you reach a certain level of subscribers who never see each other. You can't read sarcasm, sincerest humility and the fact that someone might not be giving you their relevant credentials just to be arrogant (especially not after you gave your own first! ;-).
Neither would a sysadmin with as much cynicism as has been displayed, or an automatic 'it broke things' when something new (and in fact improved) comes along get a job here. Do realize that this list is archived, and that many people
who
are hiring might use Google to find your name (or mine, for that matter).
Then according to that logic, I should _never_ have a job. ;->
REALITY:
Just because the majority disagrees with you doesn't mean that you're necessarily wrong. Ironically, I've gotten no less than 2 salaried jobs and more than a dozen clients because I was someone on a list _very_few_people_ openly agreed with in a discussion. This has happened time and time again to me -- I'll get a call with an offer for a job because I did not bow down to "popular view" on something!
So excuse me if I don't really care for this continued stream of meta-discussions about what goes on here (I'm not saying you're responsible for that -- many others have already preceeded yourself). People are right, people are wrong, people are whatever from their viewpoints. I don't like the "absolutism" I see on SELinux, Red Hat, etc... and I'll sound off, but I leave it there. I don't "hate" anyone -- in fact, the only things I really mind are the people that regularly bring up the fact that they are blocking me, but feel the need to comment on me (So you're blocking me so you see anyting so you won't talk about me? Or you just like making a "big deal" about me? ;-).
In the end, I _never_ say people aren't entitled to their opinions -- no matter how misguided or narrowminded I might feel they might be. Why? Because I'm sure many others think the same about me too -- so I can't fault people for doing what I also do in the eyes of others.
Now if you're a hypocrite, then you'll get my scorn. ;-> Don't try to lecture me about my commentary when you've done the exact same things. That's a sure-fire way to lose my respect. But as long as you aren't a hypocrite, I could _care_less_ what you do in e-mail, because most of us have _all_ done it too!
Bryan Smith, for all the verbosity he is known for, doesn't seem to be lazy and could likely hold the job;
Others might disagree. There have been several incidents in my professional life where people got so disgusted with me in e-mail that they call my employer or, in the case of one person, even made criminal accusations against me to the authorities.
Did I ever work with these people? No.
Ironically enough, it's been the ones I show the most chartity to in real-life (consulting for free, writing scripts/programs for free, etc...) that I find get "fixated" after I've "bailed them out. Including the one who made a criminal accusation, I helped him more than anyone in my life.
[ Of course, in doing that, he cut his own throat, and very few in our LUG will help him every again, and the few that have tried now agree with me. ;-]
The main reason I think sysadmins in general seem to hate SELinux is the 'Mandatory' part of 'Mandatory Access
Control'
Once again, you say it shorter and sweeter than I could ever. ;->
I really thought my analogy to a firewall with a deny-all outgoing default policy was a good one. Apparently not?
Also, as one poster wrote, SELinux is NOT a *service* but is indeed the Bully Boss of the system.
Agreed, and that's how I responded as well.
On Wed, 2005-11-16 at 14:12, Lamar Owen wrote:
The main reason I think sysadmins in general seem to hate SELinux is the 'Mandatory' part of 'Mandatory Access Control' : that is, superuser power is too addictive to get rid of, and SELinux can do away with 'superuser' powers entirely.
Not exactly. In my case I just realize that there are 30 years of history behind expecting all unix access control to be in the filesystem in the owner, group and modes of the files. It will take a while to rewrite everything based on different assumptions, and meanwhile things will mysteriously not work.
AND THAT IS A GOOD THING. Yes, it really is. The buffer overflow exploit for those root-running daemons doesn't stand a chance even if it gains root, as long as the selinux policies are set properly.
We are talking about bugs here. Why are you so convinced that the new code you just introduced to enforce this new policy does not in fact introduce new bugs? Remember that old code that you are trying to protect has many, many years of finding and fixing exploits. They may in fact all be fixed now and you are just setting up new ones that we don't know about yet with this change regardless of how well-intentioned it is.
I have been running Red Hat Linux on internet-facing servers for quite a while, now, and in my opinion and experience, SELinux is the best thing to happen to Linux since 0.13 was released.
Have you watched the changelogs to see if in fact any problems have been found and fixed so far?
The Real Root should take the time to configure in to the policies those things the Real Root would normally do (you know, things like backups and the like, along with other normal activities),
Speaking of backups, have you tested the method you use to make sure it restores the attributes SELinux needs to work?
On Wednesday 16 November 2005 15:45, Les Mikesell wrote:
On Wed, 2005-11-16 at 14:12, Lamar Owen wrote:
The main reason I think sysadmins in general seem to hate SELinux is the 'Mandatory' part of 'Mandatory Access Control' : that is, superuser power
Not exactly. In my case I just realize that there are 30 years of history behind expecting all unix access control to be in the filesystem in the owner, group and modes of the files.
A single superuser who can do anything is, IMHO at least, the single worst feature of Unix-like systems. No single user should ever have 'do everything' rights once the system is running multiuser. Of course, there should be administrator oversight on making sure that 'someone' can do 'anything' that might need to be done while in multiuser, but some things are best done in singleuser mode, where a superuser actually makes some sense.
It will take a while to rewrite everything based on different assumptions, and meanwhile things will mysteriously not work.
Judging from the contents of many messages to several lists I am on, the standard permissions system has its own share of 'mysteriously not work' issues. Yes, with more control comes more responsibility.
AND THAT IS A GOOD THING. Yes, it really is. The buffer overflow exploit for those root-running daemons doesn't stand a chance even if it gains root, as long as the selinux policies are set properly.
We are talking about bugs here. Why are you so convinced that the new code you just introduced to enforce this new policy does not in fact introduce new bugs?
There will always be one more bug. (There's you a one-liner, Peter Farrow.) Is the bug in the filesystem? Is it in the policies themselves? Does it matter where the bug is/will be? Regardless of code maturity, there will be bugs; it is a red herring to say 'turn it off' because there might be bugs in it; you might as well never boot at all if you really believe that mindset.
As to why am am convinced about the stability of SELinux in particular, well, the original developer is known for being thorough in auditing code and practices. The original SELinux developer wrote the book (which is probably classified!) on code auditing. The built-in distrust of the original developer means that more qualified eyes are on this code that virtually any other major piece of code in the kernel. Is it perfect? No, and will never be perfect. Is it an improvement over permissions? Yes, and it augments them nicely.
Have you watched the changelogs to see if in fact any problems have been found and fixed so far?
In a cursory manner, yes.
The Real Root should take the time to configure in to the policies those things the Real Root would normally do (you know, things like backups and the like, along with other normal activities),
Speaking of backups, have you tested the method you use to make sure it restores the attributes SELinux needs to work?
Yes.
On Wed, 2005-11-16 at 15:53, Lamar Owen wrote:
The main reason I think sysadmins in general seem to hate SELinux is the 'Mandatory' part of 'Mandatory Access Control' : that is, superuser power
Not exactly. In my case I just realize that there are 30 years of history behind expecting all unix access control to be in the filesystem in the owner, group and modes of the files.
A single superuser who can do anything is, IMHO at least, the single worst feature of Unix-like systems.
That's not the only thing affected by SELinux, though. It changes all the assumptions of any process you let it manage. These programs may have configurations and data in places that developed over decades and access patterns that no current sysadmin understands all working just fine with user/group permissions.
If you have no existing services in place and are starting from scratch you might not have the same issues.
No single user should ever have 'do everything' rights once the system is running multiuser.
That's fine if you are willing to pay 3 people to do one job and spy on each other. So far no place I've worked has done that.
Of course, there should be administrator oversight on making sure that 'someone' can do 'anything' that might need to be done while in multiuser, but some things are best done in singleuser mode, where a superuser actually makes some sense.
How many people should it take to do a restore? If it is one, that person ultimately controls what's on your disk.
It will take a while to rewrite everything based on different assumptions, and meanwhile things will mysteriously not work.
Judging from the contents of many messages to several lists I am on, the standard permissions system has its own share of 'mysteriously not work' issues. Yes, with more control comes more responsibility.
There are ways to go wrong with user/group permissions and suid but things that work don't mysteriously stop working.
We are talking about bugs here. Why are you so convinced that the new code you just introduced to enforce this new policy does not in fact introduce new bugs?
There will always be one more bug. (There's you a one-liner, Peter Farrow.) Is the bug in the filesystem? Is it in the policies themselves? Does it matter where the bug is/will be?
Yes, it matters whether or not it affects your system.
Regardless of code maturity, there will be bugs; it is a red herring to say 'turn it off' because there might be bugs in it; you might as well never boot at all if you really believe that mindset.
My experience says don't turn it on while many other users are frequently reporting surprises. That still seems to be the case. When the reports of problems become rare and are answered immediately with the correct response to work around or avoid the problem, it is time to start thinking about using code in production.
Speaking of backups, have you tested the method you use to make sure it restores the attributes SELinux needs to work?
Yes.
Which filesystem(s) and method(s) have you verified?
On Wed, 2005-11-16 at 15:53, Lamar Owen wrote: That's not the only thing affected by SELinux, though. It changes all the assumptions of any process you let it manage. These programs may have configurations and data in places that developed over decades and access patterns that no current sysadmin understands all working just fine with user/group permissions.
Buffer overflows don't care about programs' assumptions. They are just trying to get root because root can do anything. 'Anything' here means 'grab me a backdoor and hold it open with a rootkit.'
No single user should ever have 'do everything' rights once the system is running multiuser.
That's fine if you are willing to pay 3 people to do one job and spy on each other. So far no place I've worked has done that.
User!=person. Daemon users are users, too, and any daemon that for some reason (like binding to ports below 1024, or delivering mail to users, or any number of other things) has to run euid 0, should be limited in what it can do to those things it normally does.
And the original developer of SELinux really does get 3 people doing one job and actively distrusting each other; this works very well in practice for that particular application.
How many people should it take to do a restore?
That has nothing to do with what I'm talking about.
If it is one, that person ultimately controls what's on your disk.
User!=person. A person (the Real Root) running a restore would be treated differently from say sendmail running as root being exploited by a buffer overflow. That is the whole point to SELinux; root!=root under all instances of euid 0.
My experience says don't turn it on while many other users are frequently reporting surprises. That still seems to be the case. When the reports of problems become rare and are answered immediately with the correct response to work around or avoid the problem, it is time to start thinking about using code in production.
Which filesystem(s) and method(s) have you verified?
Software RAID1 hotswap (that is, break the mirror, swap out a drive, swap in a new, reestablish the mirror). Doable with many SCSI controllers, including the popular NCR/Symbios family. I keep hotswap carriers for the purpose. The RAID1 mirror is filesystem-agnostic. Cheaper than tape or DVD. When SATA hotswap works will do it with SATA carriers; currently the hardware will allow the hotplug, but the kernel has problems dealing with it. If FireWire or USB drives could reliably join a software RAID, would use that, but those are troublesome.
I haven't had trouble with SCSI devices, as long as I do things in order (sync;hotdrop the drive;stop the drive with the SCSI ioctls; pull the carrier (the carriers I use are made by StorCase under the brand 'Data Express'; I have the 68-pin Ultra2 SCSI versions with the bus isolator/repeater cards for true hotswap); push in new drive in carrier;rescan/add the SCSI drive using the SCSI ioctls; add drive to RAID1 and activate). It works, and I've used it. For restoring files, rather than hotadding to the same RAID1 add it to a different md device and mount it as a degraded array. To restore whole disks, the trick is to remember that a RAID1 is not limited to two drives. Works here on my hardware.
I have some other controllers that I'm going to try where the break/rebuild is more automatic, but haven't had time to do much with them as yet.
On Wed, 2005-11-16 at 21:41, Lamar Owen wrote:
That's not the only thing affected by SELinux, though. It changes all the assumptions of any process you let it manage. These programs may have configurations and data in places that developed over decades and access patterns that no current sysadmin understands all working just fine with user/group permissions.
Buffer overflows don't care about programs' assumptions. They are just trying to get root because root can do anything. 'Anything' here means 'grab me a backdoor and hold it open with a rootkit.'
But hardly anything runs as root all the time anymore. What it affects instead is all the carefully crafted suid-so-you-can-run-under-cgi programs that have a myriad of users with different file areas all under the same httpd process that have taken years to get right - and now they break under SELinux because it isn't just filesystem permissions involved.
User!=person. Daemon users are users, too, and any daemon that for some reason (like binding to ports below 1024, or delivering mail to users, or any number of other things) has to run euid 0, should be limited in what it can do to those things it normally does.
Yes, but it took years to get the uid/permission/limits right with one model and it will take more to overlay that with another layer. It isn't that it's a bad idea, it just isn't practical to drop into a working complex system.
User!=person. A person (the Real Root) running a restore would be treated differently from say sendmail running as root being exploited by a buffer overflow. That is the whole point to SELinux; root!=root under all instances of euid 0.
The ones to worry about are ssh and login. Sendmail hasn't had an exploit in a long time and only runs as root to open port 25. How can SELinux determine that it is or isn't me logging in?
Which filesystem(s) and method(s) have you verified?
Software RAID1 hotswap (that is, break the mirror, swap out a drive, swap in a new, reestablish the mirror). Doable with many SCSI controllers, including the popular NCR/Symbios family. I keep hotswap carriers for the purpose. The RAID1 mirror is filesystem-agnostic. Cheaper than tape or DVD.
But how can you scale that? I've got a dozen machines being backed up to tape with amanda and 30 or so by backuppc.
When SATA hotswap works will do it with SATA carriers; currently the hardware will allow the hotplug, but the kernel has problems dealing with it. If FireWire or USB drives could reliably join a software RAID, would use that, but those are troublesome.
I do a raid sync to an external firewire of the backuppc drive (which otherwise is next-to-impossible to copy because of all the hardlinks) weekly, but I wouldn't want to to that for every box running any services.
I haven't had trouble with SCSI devices, as long as I do things in order (sync;hotdrop the drive;stop the drive with the SCSI ioctls; pull the carrier (the carriers I use are made by StorCase under the brand 'Data Express'; I have the 68-pin Ultra2 SCSI versions with the bus isolator/repeater cards for true hotswap); push in new drive in carrier;rescan/add the SCSI drive using the SCSI ioctls; add drive to RAID1 and activate). It works, and I've used it.
I've done this to repair on-line raids but I've also had machines crash when hot-swapping SCSIs. Not often, but its enough of a risk that I wouldn't do it to a production machine unless something was already broken.
For restoring files, rather than hotadding to the same RAID1 add it to a different md device and mount it as a degraded array. To restore whole disks, the trick is to remember that a RAID1 is not limited to two drives. Works here on my hardware.
You can actually mount the underlying partition of the md raid1 directly. I can mount my backuppc mirror in my laptop (where I also have backuppc installed) and restore from there. But it isn't going to deal with those extended attributes because the actual copies are done with tar and rsync.
But hardly anything runs as root all the time anymore. What it affects instead is all the carefully crafted suid-so-you-can-run-under-cgi programs that have a myriad of users with different file areas all under the same httpd process that have taken years to get right - and now they break under SELinux because it isn't just filesystem permissions involved.
And they are broken. SELinux serves a valid need; at least in Red Hat's opinion. I happen to share that opinion.
SELinux didn't break the programs to which you refer; your description pretty much says outright that they are broken. Seems to me the purveyors of such programs need to learn to work within the system as it stands; but then again web-based administration ala Webmin isn't the most secure thing in the world to begin with. But that's somewhat philosophical, and certainly quite off-topic.
What is on-topic is the simple fact that CentOS ships with SELinux on by default; this is the way things are, whether you or I like it or not. I happen to like it; YMMV. I quite strongly disagree that the answer to SELinux problems should be 'turn it off' as this is the lazy way out.
Yes, but it took years to get the uid/permission/limits right with one model and it will take more to overlay that with another layer. It isn't that it's a bad idea, it just isn't practical to drop into a working complex system.
Yet it has been dropped into a working complex system, and apparently it is working fine for lots of people (myself included). There have been issues, certainly (the closest one to me was the PostgreSQL initdb-related one; simple enough to fix once you are aware of it). Turning it off isn't the answer; learning to live with it and learn to use its strengths is the answer. It is Red Hat's default; thus it is (at least has been) CentOS's default. The targeted policy works pretty well most of the time, and it isn't too difficult to work with. I think it's pretty cool to restrict what a program can do beyond the very coarse-grained user-based permissions.
Deny by default; allow only what is needed. If every single program and process in the system were to follow that simple mantra, viruses and worms simply would cease to exist.
The ones to worry about are ssh and login. Sendmail hasn't had an exploit in a long time and only runs as root to open port 25. How can SELinux determine that it is or isn't me logging in?
If through ssh or by command line login, it can't. But it can present restrictions on what can be done once you are logged in; once you configure them. But, as it has already been observed, password-based ssh login is passe anyway, RSA/DSA-only auth is the way to go. Carry your keys on that USB key for use.
However, other things run as root: samba syslog various RPC daemons xinetd cupsd portmap httpd starts as root and leaves a process running as root (at least on this CentOS4 box).
What some seem to not realize is that perhaps much of the permissions spaghetti we have now could be avoided entirely (I'm thinking local mail delivery for one, print spooling for another, CD recording, USB devices, etc....) with SELinux policies.
Which filesystem(s) and method(s) have you verified?
Software RAID1 hotswap (that is, break the mirror, swap out a drive,
But how can you scale that? I've got a dozen machines being backed up to tape with amanda and 30 or so by backuppc.
You asked what I used and if I had verified it. I answered the question. I have a smaller number of boxes to deal with; they are large boxes in some cases (14 CPU Sun E6500 with 16GB RAM for one running Aurora Kashmir) but a smaller quantity. I have a mere 25 or so, and most are Windows boxes storing stuff on the main fileserver, which has the RAID1 trick being used.
In most cases the portions that SELinux is dealing with aren't necessary to backup in the first place. I want to protect user's data using backups; star seems capable of doing that easily enough with EA support. But even then a restore and relabel for non-EA backups of user data isn't likely to be a real problem. And programs can be restored with other methods.
SELinux is at its best preventing programs from opening unauthorized network sockets or listening on unauthorized ports, or enforcing read-only access to certain portions of the file system from non-interactive programs, etc.
Special policies for yum, for instance, could be written to allow yum to do its work but not allow other programs run from the root shell to overwrite essential things in areas like /bin, /sbin, /lib/modules, and /boot. Rootkit Prevention 101: read-only system files. System Updating 101: frequent updates. But how do you allow updates while making your system files read-only? My understanding of SELinux is that it can do this, with the proper policies in place. This cannot be done using traditional permissions without wierd things being done (although SELinux might qualify as a wierd thing in your book... :-)).
But the fact again is that this discussion is pretty pointless in light of the fact that CentOS does ship with SELinux; the default is targeted and enforcing, and that this behavior is desirable for the upstream distributor (and CentOS has thus far had a policy of remaining close to the upstream distributor).
On Thu, 17 Nov 2005, Lamar Owen wrote:
What is on-topic is the simple fact that CentOS ships with SELinux on by default; this is the way things are, whether you or I like it or not. I happen to like it; YMMV. I quite strongly disagree that the answer to SELinux problems should be 'turn it off' as this is the lazy way out.
That's a bit too declarative for my taste. It certainly could be the lazy way out -- or it could be a sysadmin asking the honest question: is it worth more to my organization *now* for me to spend X hours figuring out SELinux policies or to spend those hours on a different project.
You and Lee both have valid points, and I appreciate the discussion. I'd be hard-pressed, however, to deride the admin who chose to install SELinux in permissive mode because s/he made an honest assessment that the time was better spent elsewhere.
It could be laziness. It could be priorities. From the cheap seats, that assessment isn't mine to make.
As for the machines under my care, most work fine in targeted mode. For now, those few that don't get the permissive treatment because, frankly, I don't have the luxury of telling my executive staff that their priorities need to wait while I solve SELinux policy issues.
running a consultancy business where time is money, tunring it off and configuring as we always did before represents the best technical solution and value for money for my clients.
Those of you who work in big corporates or have time to experiment with every last detail of SELinux features in a lab by all means go and do it, here at the coal face its rather like offering options for window dressing while we are still building the shop front....
Turning it off stops all the junk filling up the logs and allows you to see the real stuff.....and is the best option for me and my clients, others may have different objectives, but my machines stay secure without it. Therefore I don't need it.... period...
P.
Paul Heinlein wrote:
On Thu, 17 Nov 2005, Lamar Owen wrote:
What is on-topic is the simple fact that CentOS ships with SELinux on by default; this is the way things are, whether you or I like it or not. I happen to like it; YMMV. I quite strongly disagree that the answer to SELinux problems should be 'turn it off' as this is the lazy way out.
That's a bit too declarative for my taste. It certainly could be the lazy way out -- or it could be a sysadmin asking the honest question: is it worth more to my organization *now* for me to spend X hours figuring out SELinux policies or to spend those hours on a different project.
You and Lee both have valid points, and I appreciate the discussion. I'd be hard-pressed, however, to deride the admin who chose to install SELinux in permissive mode because s/he made an honest assessment that the time was better spent elsewhere.
It could be laziness. It could be priorities. From the cheap seats, that assessment isn't mine to make.
As for the machines under my care, most work fine in targeted mode. For now, those few that don't get the permissive treatment because, frankly, I don't have the luxury of telling my executive staff that their priorities need to wait while I solve SELinux policy issues.
Peter Farrow peter@farrows.org wrote:
running a consultancy business where time is money, tunring it off and configuring as we always did before represents
the
best technical solution and value for money for my clients. Those of you who work in big corporates or have time to experiment with every last detail of SELinux features in a
lab
by all means go and do it, here at the coal face its rather like offering options for window dressing while we are
still
building the shop front.... Turning it off stops all the junk filling up the logs and allows you to see the real stuff.....and is the best option for me and my clients, others may have different
objectives,
but my machines stay secure without it. Therefore I don't need it.... period...
You brought up an excellent side-point. Consulting. Not just fly-by-night consultants, but their over-expecting clients.
Consulting is why the IT infrastructure and security of this country has gone to crap. There is no accountability. There is only the pressure to complete things in unrealistic timeframes.
It's why control systems fail at power plants. It's why financial backends are compromised.
I've been overridden time and time again on bank systems security designs because it was deemed "unsupportable." Why? Because someone had to physically come over to a secured network. WTF?
Sound security policy has been put out-the-window by consulting, support non-sense, etc... You have to "tear it down" so you can "dumb it down" for people. And it happens in the most crucial of our nation's networks.
Why? Consultants aren't accountable in most cases. And that's typically because the clients want it done now.
On Thursday 17 November 2005 11:40, Peter Farrow wrote:
running a consultancy business where time is money, tunring it off and configuring as we always did before represents the best technical solution and value for money for my clients.
No, it's the easiest solution, but not the best technical one. The best technical solution is where you figure out how to use it and leverage it for value-add to your customers.
Those of you who work in big corporates or have time to experiment with every last detail of SELinux features in a lab by all means go and do it, here at the coal face its rather like offering options for window dressing while we are still building the shop front....
No, it's more like choosing sheet steel studs instead of spruce studs in the framing, as SELinux is pretty tightly integrated. It's definitely something you want to design in and take advantage of, not just throw on like a skin.
but my machines stay secure without it.
As far as you know....
Therefore I don't need it.... period...
One rootkit is probably all it will take. Just because you've never yet been hacked doesn't mean you won't be hacked. Been there, done that. Cleaned up a couple of rootkits after the fact, too.
And the same goes here; while I've not yet been cracked here (as far as I know), that could change in an instant, and that's with SELinux in targeted mode as opposed to full enforcing mode.
But if you think you don't need it, well, that's your choice. But that doesn't mean that the correct answer to everyone who has some difficulty with SELinux is 'turn it off.'
On 17/11/05, Lamar Owen lowen@pari.edu wrote:
When SATA hotswap works will do it with SATA carriers; currently the hardware will allow the hotplug, but the kernel has problems dealing with it.
I've had no problems hot-swapping SATA drives on 3Ware 8006-2LP controllers using Vantec MRK-200ST-BK drive bays and caddys. It must be said this is just disks in JBOD mode though, no underlying hardware or overlying software RAID.
You can "park" the disks in 3warecli, swap them out and then rescan for new disks[1].
The drive caddys are a bit "boy-racer" and not as solid as good SCA caddys from say Compaq or Dell but they do the job.
Will.
[1]
[root@backupserv sbin]# 3warecli 3ware CLI> info List of controllers ------------------- Controller 2: 8006-2LP (2) 3ware CLI> info c2 Controller: c2 ------------- Driver: 1.26.00.039 Model: 8006-2LP FW: FE8S 1.05.00.068 BIOS: BE7X 1.08.00.048 Monitor: ME7X 1.01.00.040 Serial #: L18501A5220444 PCB: Rev5 PCHIP: 1.30-66 ACHIP: 3.20
# of units: 2 Unit 0: JBOD 372.61 GB ( 781422768 blocks): OK Unit 1: JBOD 372.61 GB ( 781422768 blocks): OK
# of ports: 2 Port 0: ST3400832AS 3NF0GD99 372.61 GB (781422768 blocks): OK(unit 0) Port 1: ST3400832AS 3NF0GE2S 372.61 GB (781422768 blocks): OK(unit 1)
3ware CLI> maint remove c2 u0 Removed unit /c2/u0, you may now safely unplug the drives. 3ware CLI> info c2 Controller: c2 ------------- Driver: 1.26.00.039 Model: 8006-2LP FW: FE8S 1.05.00.068 BIOS: BE7X 1.08.00.048 Monitor: ME7X 1.01.00.040 Serial #: L18501A5220444 PCB: Rev5 PCHIP: 1.30-66 ACHIP: 3.20
# of units: 1 Unit 1: JBOD 372.61 GB ( 781422768 blocks): OK
# of ports: 2 Port 1: ST3400832AS 3NF0GE2S 372.61 GB (781422768 blocks): OK(unit 1) 3ware CLI> maint rescan Rescanning controller /c2 for units and drives ...Done.
3ware CLI> info c2 Controller: c2 ------------- Driver: 1.26.00.039 Model: 8006-2LP FW: FE8S 1.05.00.068 BIOS: BE7X 1.08.00.048 Monitor: ME7X 1.01.00.040 Serial #: L18501A5220444 PCB: Rev5 PCHIP: 1.30-66 ACHIP: 3.20
# of units: 2 Unit 0: JBOD 372.61 GB ( 781422768 blocks): OK Unit 1: JBOD 372.61 GB ( 781422768 blocks): OK
# of ports: 2 Port 0: ST3400832AS 3NF0GD99 372.61 GB (781422768 blocks): OK(unit 0) Port 1: ST3400832AS 3NF0GE2S 372.61 GB (781422768 blocks): OK(unit 1) 3ware CLI>
Will McDonald wmcdonald@gmail.com wrote:
I've had no problems hot-swapping SATA drives on 3Ware 8006-2LP controllers
That's because the 3Ware controller is a _true_ hardware RAID. The _physical_ hardware is never seen by the kernel -- it's not some logical organization, but _physical_.
The kernel only talks to the ASIC. The ASIC talks to the disks. The kernel _never_ talks to the disks.
"FRAID" cards just hide the disks in software. The kernel still very much sees the "raw" ATA channels. That's why you need hotplug for FRAID.
But not for 3Ware.
You can "park" the disks in 3warecli, swap them out and then rescan for new disks[1].
That's because you're commanding the ASIC to do this, and the geometry of the volume _never_ changes from the standpoint of the kernel from a _physical_ (i.e., electrical) standpoint.
The drive caddys are a bit "boy-racer" and not as solid as good SCA caddys from say Compaq or Dell but they do the
job.
SATA is staggered connectors for power, if you're using it in it's native connector mode (no Molex).
On Thursday 17 November 2005 11:42, Will McDonald wrote:
I've had no problems hot-swapping SATA drives on 3Ware 8006-2LP controllers using Vantec MRK-200ST-BK drive bays and caddys. It must be said this is just disks in JBOD mode though, no underlying hardware or overlying software RAID.
You can "park" the disks in 3warecli, swap them out and then rescan for new disks[1].
This is good information. Thanks.
Ron Jones wrote:
No single user should ever have 'do everything' rights once the system is running multiuser.
That's fine if you are willing to pay 3 people to do one job and spy on each other. So far no place I've worked has done that.
That sounds to me like a taxpayer-funded environment :-))
Exactly. And SELinux was developed by the NSA who probably has 30 people doing every task and each one spying on the other 29. If you need that level of security/complexity mazel tov. If you don't, just turn it off.
Cheers,
Les Mikesell lesmikesell@gmail.com wrote:
Not exactly. In my case I just realize that there are 30 years of history behind expecting all unix access control to be in the filesystem in the owner, group and modes of the files.
But is it? You have root, so such access is _bypassed_! Superuser is incompatible with a complete RBAC/MAC. ;->
We are talking about bugs here. Why are you so convinced that the new code you just introduced to enforce this new policy does not in fact introduce new bugs?
There is a _world_ of difference between bugs in a service, and bugs in a kernel supervisory RBAC/MAC that prevents a service from doing what it shouldn't.
Let's go back to my analogy to firewalls ...
Which is more dangerous?
A) Allows all outgoing access by default, then deny certain access?
B) Deny all outgoing access by default, then write writes to allow certain acces?
In the majority of cases, a firewall doing "B" will prevent someone from doing something you didn't expect than "A".
RBAC/MAC isn't about addressing how you think someone might circumvent a service from what it's normally supposed to be allowed to do. That's traditional "hardening" like "B" in a firewall. ;->
RBAC/MAC is about only allowing what you think someone should be able to do from a service and _denying_everything_ else. That's like "B".
"B" is a major PITA because you find something that you have to allow through, then test again and find yet another, yet another, then yet another ... and you get tired of it. Same deal with RBAC/MAC, you prevent everything by default, then enable something, then another thing, then another thing and ... damn it ... it still won't work!
With "A" ... yeah, it works much quicker! But it requires you to think of _anything_ a service might try to do. Well, if that was the case, why don't we just fix the bugs in the service instead of doing "A"?
Exactly! We do "B" because we don't know all the bugs or what could happen! Defense-in-depth -- we try to write bug-free code, but then we use RBAC/MAC to enforce things in case we missed something.
Remember that old code that you are trying to protect has
many,
many years of finding and fixing exploits. They may in
fact
all be fixed now and you are just setting up new ones that
we
don't know about yet with this change regardless of how well-intentioned it is.
Ummm, no. RBAC/MAC _prevents_additional_ access over traditional UNIX DAC security. It supplements it, it does _not_ remove legacy DAC security. That's a misnomer. ;->
Have you watched the changelogs to see if in fact any problems have been found and fixed so far?
Yes. New rulesets come out regularly on Rawhide.
Speaking of backups, have you tested the method you use to make sure it restores the attributes SELinux needs to work?
That why I _hate_ Ext3. Only Star does this, and I don't trust it. e2dump is a joke.
With XFS, there is no issue. It's in the inode and gets backed up with xfsdump.
I agree with you 100%, if Red Hat is _serious_ about SELinux, they really need to address the filesystem/backup issue.
Corrected version ...
"Bryan J. Smith" thebs413@earthlink.net wrote:
There is a _world_ of difference between bugs in a service, and bugs in a kernel supervisory RBAC/MAC that prevents a service from doing what it shouldn't. Let's go back to my analogy to firewalls ... Which is more dangerous? A) Allows all outgoing access by default, then deny certain access? B) Deny all outgoing access by default, then write writes to allow certain acces?
B) Deny all outgoing access by default, the write rights (rules) to allow certain access?
In the majority of cases, a firewall doing "B" will prevent someone from doing something you didn't expect than "A". RBAC/MAC isn't about addressing how you think someone might circumvent a service from what it's normally supposed to be allowed to do. That's traditional "hardening" like "B" in a firewall. ;->
Er, that's traditional "hardening" like "A" in a firewall.
[ You try to figure out how something can be circumvented and used and attempt deny to deny. ]
RBAC/MAC is about only allowing what you think someone should be able to do from a service and
_denying_everything_
else. That's like "B". "B" is a major PITA because you find something that you have to allow through, then test again and find yet
another,
yet another, then yet another ... and you get tired of it. Same deal with RBAC/MAC, you prevent everything by default, then enable something, then another thing, then another
thing
and ... damn it ... it still won't work!
With "A" ... yeah, it works much quicker! But it requires you to think of _anything_ a service might try to do. Well, if that was the case, why don't we just fix the bugs
in
the service instead of doing "A"?
Exactly! We do "B" because we don't know all the bugs or what could happen! Defense-in-depth -- we try to write bug-free code, but then we use RBAC/MAC to enforce things in case we missed something. ... Ummm, no. RBAC/MAC _prevents_additional_ access over traditional UNIX DAC security. It supplements it, it does _not_ remove legacy DAC security. That's a misnomer. ;->
It's just like a deny-all outgoing default policy on a firewall.
We know that a compromised system might have Sub7 and countless other rootkits installed. So we block those outgoing, destination ports they commonly use.
But what about the rootkits we don't know about? Blocking _all_ ports by default would catch those!
Lamar Owen wrote:
After reading through the various SELinux threads, I really became quite perturbed. I mean, really quite perturbed.
If you get perturbed over something so trivial, perhaps it's time to re-examine your priorities in life. 8-)
As an IT Director (and the entire IT department, currently), if I were hiring a sysadmin I know for a fact that someone whose first response to a question on why something doesn't work is 'turn it off' would not get a job here.
Thank goodness I'm not an SA then. I also run, and have run in the past, rather large IT departments. I also started out my unix life as a SA. Now that we've gotten that out of the way...SELinux shouldn't be turned on by default and in many cases simply creates extra overhead/bloat on a system that doesn't really need it. Building a firewall? Building a hardened box that's going to be exposed to the net at a datacenter? Great, then it might be worth your while to wrestle with it and take the time to figure out why it's breaking your applications. All the really good SAs I've ever had, tended to be somewhat frugal with their time and tended not to waste it on things they didn't absolutely need or that didn't somehow make their lives easier.
Neither would a sysadmin with as much cynicism as has been displayed, or an automatic 'it broke things' when something new (and in fact improved) comes along get a job here. Do realize that this list is archived, and that many people who are hiring might use Google to find your name (or mine, for that matter).
Fantastic! I'll also state for the record here that I won't dig ditches. So any potential employer intending to hire me for ditch digging or sysadmining and is googling net archives can stop reading now. *shrug*
Cheers,
Chris Mauritz chrism@imntv.com wrote:
SELinux shouldn't be turned on by default and in many cases simply creates extra overhead/bloat on a system that
doesn't
really need it.
Okay, I give. I would like people to quantity/quality "doesn't really need it." I've really "bit my lip" on this since just after the early stuff, but it keeps coming up over and over.
Frankly, I have to join in the viewpoint of others who run some serious IT operations. People who don't see the value in RBAC/MAC are just ... and I'm sorry I have to say it this way ... "naive"?
It's more than just CC EAL certification. It's about defense-in-depth.
Building a firewall?
But how many filters these day are no longer just doing layer-2 frame, layer-3 IP or NAT and layer-4 service/PAT? They are now doing proxying at the layer-5/6/7 session, presentation and application filtering? Those are intelligent filters, a running service, and they need to be contained at the kernel.
Building a hardened box that's going to be exposed to the
net
at a datacenter?
RBAC/MAC is not just for Internet exposed systems. If you honestly aren't applying a set of defense-in-depth of several layers in a SMB or later, then you're really ignoring a lot. RBAC/MAC is just as important for internally exposed systems -- private networks between companies, VPN clients from off-site who might be compromised, etc... It's about keeping out the unexpected.
Having some kernel-level RBAC/MAC saved me about 40 hours of work when someone put the wrong data on the wrong network. I could show, _in_detail_, how far that data reached into my network, and where the data did not go. Now that's just auditing.
Let's talk about a compromise of a partner company -- one that had certain privilege access to some of my systems. 2 sets of internal firewalls, totally bypassed because the access by that system was legit to the layer-2-4 packet inspection! They got into my system with that privileged access, but thanx to RBAC, they couldn't run but a few binaries and access a few files!
[ NOTE: The system wasn't Linux. ;-]
Great, then it might be worth your while to wrestle with it and take the time to figure out why it's breaking your applications.
That's what I have to do everytime I put in a layer-2-4 packet inspector that denies _all_ traffic by default, or when I put in HTML/XML layer-7 gateways for richer services. Now I'm just doing it at the application server itself -- guaranteeing that some services can't be used to access areas of the box, possible the rest of the subnet (c/o that box), thanx to RBAC/MAC.
All the really good SAs I've ever had, tended to be
somewhat
frugal with their time and tended not to waste it on things
they didn't absolutely need or that didn't somehow make their lives easier.
Making their lives easier is the problem. Far too often people get something to work and leave it. Or they blindly believe something is secure -- especially a layer-7 service by a layer-2-4 stateful packet inspector.
The effort put forth in an environment that calls for RBAC/MAC is well worth the reduced headaches. Net-facing or non-net-facing. Heck, having a physical connection to anything is the root problem -- no matter how many filters things go through, there is always a way! And I've seen it too!
Chris Mauritz wrote:
Lamar Owen wrote:
After reading through the various SELinux threads, I really became quite perturbed. I mean, really quite perturbed.
If you get perturbed over something so trivial, perhaps it's time to re-examine your priorities in life. 8-)
Indeed. It's nothing personal. We're not your employees. What's to get perturbed about? I personally DO use SELinux. Everything works, so I don't bother turning it off. But I can see how it gets in the way for others.
Neither would a sysadmin with as much cynicism as has been displayed, or an automatic 'it broke things' when something new (and in fact improved) comes along get a job here. Do realize that this list is archived, and that many people who are hiring might use Google to find your name (or mine, for that matter).
What you said there was really funny. So let's assume said fictional employer Googles to see what Lamar Owen is up to. What's going to look worse, people turning off SELinux or someone getting "perturbed" because someone turned off SELinux? People skills are part of any job usually.
Fantastic! I'll also state for the record here that I won't dig ditches. So any potential employer intending to hire me for ditch digging or sysadmining and is googling net archives can stop reading now. *shrug*
Cheers,
:-)
Preston
Preston Crawford me@prestoncrawford.com wrote:
People skills are part of any job usually.
E-mail is not a form of people skills. In fact, if you handle people in e-mail, instead of just walking over to their office, or picking up the phone, then you're not giving them a sense of attention, not involved voice, tone, body language, etc...
I avoid e-mail like the black plague at work. It's so much easier to walk over or call them if they are afar. Leave voice mails. Use only e-mail/text to send them electronic info or notices, _not_ for conversation.
I couldn't be a trainer, consultant, architect, etc... if my people skills were as bad in person as they are in e-mail. If I need to put something in writing, I'm going to write formal in a typeset or DTP, not the jibberish I normally put out on lists like this in text.
On Thursday 17 November 2005 18:53, Preston Crawford wrote:
What you said there was really funny. So let's assume said fictional employer Googles to see what Lamar Owen is up to. What's going to look worse, people turning off SELinux or someone getting "perturbed" because someone turned off SELinux? People skills are part of any job usually.
Well, first they're going to wonder why a basketball star is an IT Director.
What got me perturbed, and still does, is the flippant attitude about the security angle. The lack of doing what is necessary to make the system secure and still usable is a real problem; I'm sure the programmer who wrote XCP for Sony is wishing they hadn't been quite so quick to release it. And I'm sure Sony is quite perturbed about the lack of their rootkit's security.
And perturbed is less intense than annoyed, or 'ticked off' or any number of other adjectives on the spectrum to livid. Perturbed is at best mildly annoyed compared to livid (yes, I know it means 'greatly disturbed or anxious': if the best and the brightest sysadmins are so careless about security, no wonder worms are running rampant, and it should be greatly disturbing to people that some sysadmins Just Don't Care).
Judging from the responses, some must have been perturbed about what I said. :-) Particularly the part about digging ditches. If learning SELinux is being compared to digging ditches, well, something isn't right. SELinux is to my mind a very fascinating vehicle for some true controls, even on myself. And this is a good thing.
On Thursday 17 November 2005 18:53, Preston Crawford wrote:
What you said there was really funny. So let's assume said fictional employer Googles to see what Lamar Owen is up to. What's going to look worse, people turning off SELinux or someone getting "perturbed" because someone turned off SELinux? People skills are part of any job usually.
Well, first they're going to wonder why a basketball star is an IT Director.
Your name is Lamar Odom?
What got me perturbed, and still does, is the flippant attitude about the security angle. The lack of doing what is necessary to make the system secure and still usable is a real problem; I'm sure the programmer who wrote
Fine. People are being flippant. So what? I take my security seriously. Every CentOS box I run uses SELinux. Others turn it off. I'm not going home steaming mad because someone else doesn't use SELinux. That's the issue now. Your reaction. Your overreaction. Your claim that someone saying SELinux is too difficult to manage now, on the Internet, should cost them a job. That's the issue now because you made it so.
For the record, I have WEP disabled at home. I just use SSH and MAC Address Filtering. Should I get turned down for a job because I don't spend hours and hours of my free time trying to get WPA (a technology that doesn't yet work properly in my experience) to work with my CentOS-running laptop? Or do we not sometimes make security decisions based on a triage of the risk and the time and effort required.
And perturbed is less intense than annoyed, or 'ticked off' or any number of other adjectives on the spectrum to livid. Perturbed is at best mildly annoyed compared to livid (yes, I know it means 'greatly disturbed or anxious': if the best and the brightest sysadmins are so careless about security, no wonder worms are running rampant, and it should be greatly disturbing to people that some sysadmins Just Don't Care).
Poor choice of words then, I guess.
Preston
On Friday 18 November 2005 21:02, Preston Crawford wrote:
Your name is Lamar Odom?
:-)
No, see http://siusalukis.collegesports.com/sports/m-baskbl/mtt/owen_lamar01.html
I get e-mail all the time asking about him. He seems to be a great player, too. Certainly has a good name. :-)
Every CentOS box I run uses SELinux. Others turn it off. I'm not going home steaming mad because someone else doesn't use SELinux. That's the issue now. Your reaction. Your overreaction. Your claim that someone saying SELinux is too difficult to manage now, on the Internet, should cost them a job. That's the issue now because you made it so.
Perhaps you too are overreacting. That seems to be in line with general list atmosphere. Perhaps I did overreact to a degree; but I'll stand by my observations. The issue for me is not SELinux per se, but the flippantly dismissive attitude that 'it's too hard' (say hard while whining...). Fine; my requirements will be too hard. I work in an environment where assumptions are challenged daily, and where one must be eager (not just willing, but eager) to learn something new every day (even if that something is the 102nd way to do the IT equivalent of ditch-digging; that is, updating those Windows boxes to the latest anti-malware junk and fixing the bugs introduced by that junk and cleaning off infections because the user disabled the junk or agreed to install spyware or such).
The utterly dismissive attitude, for better or for worse, did get on my nerves, and the original poster wasn't getting the answer he needed except by going to another list. Is that not disturbing?
What is so odd is that there is a general atmosphere of overreacting here. A question is made, and 75% of the answers are likely to be 'oh, you don't want to do that at all.'
For the record, I have WEP disabled at home. I just use SSH and MAC Address Filtering. Should I get turned down for a job because I don't spend hours and hours of my free time trying to get WPA (a technology that doesn't yet work properly in my experience) to work with my CentOS-running laptop?
If the job was at a wireless internet company, I don't think I would mention that tidbit. Other general jobs, sure, there shouldn't be a problem. My atmosphere is one that requires an open mind to new technologies (like hanging an Ethernet Labjack UE9 (labjack.com) off a fiber-connected Ethernet switch in the feedbox of a 26m dish (http://www.pari.edu/telescopes/RadioTelescopes/26East) and accessing it with a python script GUI from halfway around the world, securely (as in Tasmania)) to perform thermal calibration (using CentOS, for that matter) (no, the UE9 is not secure by design). We think outside the box; I have no use for someone who isn't _eager_ to learn new technologies.
Or do we not sometimes make security decisions based on a triage of the risk and the time and effort required.
Of course we do. And in triage the most critical injury will get fixed first. What is the most critical injury on academic networks today? Think about it a while, as it's not what you think; but rooting a box has a lot to do with it, and it's on the inside network typically.
On Fri, 2005-11-18 at 20:30, Lamar Owen wrote:
What is the most critical injury on academic networks today? Think about it a while, as it's not what you think; but rooting a box has a lot to do with it, and it's on the inside network typically.
Unless its different than every other network, it's windows boxes loaded with spyware and spam-sending zombies.
On Friday 18 November 2005 21:59, Les Mikesell wrote:
On Fri, 2005-11-18 at 20:30, Lamar Owen wrote:
What is the most critical injury on academic networks today? Think about it a while, as it's not what you think; but rooting a box has a lot to do with it, and it's on the inside network typically.
Unless its different than every other network, it's windows boxes loaded with spyware and spam-sending zombies.
Yes, this is correct. What are the lessons a Linux admin can learn from the Windows malware scourges, some of which don't require you to be running as an administrator-equivalent?
If anything, the spyware/zombie scourge should be the driving force behind SELinux adoption to prevent the same thing from happening to the Linux boxes (a well-place root hole and a linux-aware Windows spyware/worm, and your Linux box is owned from the inside). Is it too far of a leap to want to nip the coming scourge in the bud? Linux boxes are not immune as long as root holes exist that can leverage root's superuser powers, unfettered by role based and mandatory access controls. If there is no superuser in the traditional sense, the root hole is useless. Completely useless.
Firewalls are of no use, either. All it takes is a root hole in a program that is visible to the inside network with all the spyware laden Windows boxes (samba or cups, perhaps); rootkit the apache httpd installation with a fragrouting daemon which uses IP over HTTP tunneling (or a rootkitted bind and IP over DNS tunneling) and you are owned, ready to become another zombie, but this time from your server. With the typical wide-open outbound firewall rules, you're even ready to become a DDoS zombie.
You might think I'm paranoid; the black hats are indeed this devious and are indeed using devices like this today. If SELinux can help plug a few cracks, then it's worth learning and using.
I have had the experience of having a box get a rootkit; it is not a pleasant experience, and taught me a valuable lesson. Yes, the box had a firewall in front of it. No, it didn't help. While it was back in 1998, it is a lesson I will never forget.
The investigators who contacted me afterwards told me that this particular incident involved over 20,000 hosts, all compromised in the space of 14 hours. Scripted, using a BIND root hole. Hit my public DNS server; used carefully crafted packets on TCP port 53 for remote root shell. Happened before the patch was available for BIND. Happened before chrooted BIND was commonly available. The first file they transferred out was /etc/shadow.
The only common advice used today that would have thwarted that exploit was running BIND chrooted. It was a necessary service, and only necessary services were running. Patches were up to date; it was exploited prior to the vulnerability being publicly disclosed. Firewall was in place; hit on and used port 53 for all communication. Did not require a reboot. Rootkit installed replaced many (but not all) system utilities and covered tracks in the system logs. SELinux would have thwarted the vulnerability as surely as chroot would.
I found the rootkit by simple visual inspection about 25 minutes after the hack; I had just come to work, and had hit the SHIFT key to deactivate the console screen saver. On that virtual console, I always left an instance of 'top' running; the display was customized to show the data I was interested in. I caught the rootkit because the rootkit version of top didn't honor my customizations.
I was alerted by CERT of the hack two weeks later. They had traced the ftp transfer of the rootkit from a known compromised server to mine. I replied that I had already contained the problem, and had rebuilt the server from distribution media, and had upgraded the version of BIND. This was when I found out the extent of the attack.
I have had the 'rare' exploit used against my servers; everything that helps security without being too cumbersome is a big win in my book.
On Fri, 2005-11-18 at 21:29, Lamar Owen wrote:
What is the most critical injury on academic networks today? Think about it a while, as it's not what you think; but rooting a box has a lot to do with it, and it's on the inside network typically.
Unless its different than every other network, it's windows boxes loaded with spyware and spam-sending zombies.
Yes, this is correct. What are the lessons a Linux admin can learn from the Windows malware scourges, some of which don't require you to be running as an administrator-equivalent?
My take on it is that windows has crammed so much code and policy into the kernel and programs that must run as administrator that they will never be able to get all the bugs out. The lesson to learn - and the one that worked for unix the last 30 years - is to keep the kernel simple with simple, well understood mechanisms, and keep complex policy out of there.
If anything, the spyware/zombie scourge should be the driving force behind SELinux adoption to prevent the same thing from happening to the Linux boxes (a well-place root hole and a linux-aware Windows spyware/worm, and your Linux box is owned from the inside).
Or not, depending on how you interpret the problem. You don't see spyware infested Centos 3.x boxes, and you don't see people afraid to keep them updated because updates routinely break their apps.
Is it too far of a leap to want to nip the coming scourge in the bud? Linux boxes are not immune as long as root holes exist that can leverage root's superuser powers, unfettered by role based and mandatory access controls.
And you reduce/eliminate those holes by keeping the code simple and well-understood.
If there is no superuser in the traditional sense, the root hole is useless. Completely useless.
That's a separate issue, not really changed by adding more complexity in the kernel where the code can do anything.
You might think I'm paranoid; the black hats are indeed this devious and are indeed using devices like this today. If SELinux can help plug a few cracks, then it's worth learning and using.
You aren't paranoid enough. Worry about SELinux adding cracks, making the kernel more complicated, and less understood - having unexpected side effects that someone will learn to exploit. Or explain why this is impossible so I can share your confidence.
I have had the experience of having a box get a rootkit; it is not a pleasant experience, and taught me a valuable lesson. Yes, the box had a firewall in front of it. No, it didn't help. While it was back in 1998, it is a lesson I will never forget.
But do you think the bugs can't be in the kernel itself?
The investigators who contacted me afterwards told me that this particular incident involved over 20,000 hosts, all compromised in the space of 14 hours.
Yes, this is what happens when everyone uses the same code, and this code wasn't even in your kernel.
Scripted, using a BIND root hole. Hit my public DNS server; used carefully crafted packets on TCP port 53 for remote root shell. Happened before the patch was available for BIND. Happened before chrooted BIND was commonly available. The first file they transferred out was /etc/shadow.
The only common advice used today that would have thwarted that exploit was running BIND chrooted.
The mechanism was there all along, the policy wasn't - and the policy didn't belong in the kernel.
On Fri, 2005-11-18 at 21:29, Lamar Owen wrote:
What are the lessons a Linux admin can learn from the Windows malware scourges, some of which don't require you to be running as an administrator-equivalent?
My take on it is that windows has crammed so much code and policy into the kernel and programs that must run as administrator that they will never be able to get all the bugs out. The lesson to learn - and the one that worked for unix the last 30 years - is to keep the kernel simple with simple, well understood mechanisms, and keep complex policy out of there.
If you look at the problem Windows NT and its children have is that it must have compatibility with the simpler, but less secure, Windows 3.0 Enhanced Mode kernel (as Win95, 98, and ME are all based off this code, which actually dates from late in the Windows 2.x 386 cycle). The problem with Windows Malware is backwards compatibility to an old code base that is not prepared for today's Internet. So much for older and simpler is better; why don't we go back to VMS? It's substantially more secure than Linux (the Linux kernel and heritage is not 30 years old, because Linux is not Unix).
And you reduce/eliminate those holes by keeping the code simple and well-understood.
So then let's get rid of the kernel code called netfilter. It will simplifyy the kernel code and thus make it more secure. Right?
If there is no superuser in the traditional sense, the root hole is useless. Completely useless.
That's a separate issue, not really changed by adding more complexity in the kernel where the code can do anything.
Where can you do robust role-based access controls (and mandatory access controls) but in the kernel? RBAC/MAC is not a service; it is not a daemon; it really does need to run in the kernel, just like the netfilter code does.
But do you think the bugs can't be in the kernel itself?
Sure, bugs can be anywhere. They can be in the filesystem code. Or the TCP/IP stack. Or virtually anywhere else in the kernel. But a bug in SELinux will not result in a non-root user gaining root; SELinux only restricts according to policy.
The only common advice used today that would have thwarted that exploit was running BIND chrooted.
The mechanism was there all along, the policy wasn't - and the policy didn't belong in the kernel.
Sure, the policy of chroot is indeed in the kernel, and the kernel enforces the chroot, no? Is chroot not a system call into the kernel? Does it not restrict what the process can see and can do? Yes, it must be configured; BIND or whatever daemon must be set up for a chroot. But the kernel enforces the change in effective filesystem root; that is not a userspace function.
The other typical answer to exploits is firewalling: pray tell where that policy is enforced.
On Sat, 2005-11-19 at 14:02, Lamar Owen wrote:
So much for older and simpler is better; why don't we go back to VMS? It's substantially more secure than Linux (the Linux kernel and heritage is not 30 years old, because Linux is not Unix).
The VMS model isn't older and simpler than unix - it is more complex and around the same age. The unix model was intentionally simplified by someone familiar with Multics, an older and much more complicated system. People have had a choice between VMS and unix for a long time and VMS found a very small niche of popularity. Linux may not be unix but it's design goal was to provide the same api - and for good reasons.
The mechanism was there all along, the policy wasn't - and the policy didn't belong in the kernel.
Sure, the policy of chroot is indeed in the kernel, and the kernel enforces the chroot, no?
No, the kernel provides the mechanism of chroot, and has more or less forever. A policy of using it or not is left up to you. Simplicity in the kernel.
The other typical answer to exploits is firewalling: pray tell where that policy is enforced.
The best place is on a separate box from anything that it should be protecting.
On Sat, 2005-11-19 at 14:02, Lamar Owen wrote:
So much for older and simpler is better; why don't we go back to VMS? It's substantially more secure than Linux (the Linux kernel and heritage is not 30 years old, because Linux is not Unix).
The VMS model isn't older and simpler than unix - it is more complex and around the same age.
It is slightly more complex, and demonstrably more secure.
system. People have had a choice between VMS and unix for a long time and VMS found a very small niche of popularity.
I have SIMH under Linux running OpenVMS Hobbyist 7.3 here. It's a fun system.
No, the kernel provides the mechanism of chroot, and has more or less forever. A policy of using it or not is left up to you. Simplicity in the kernel.
This is not unlike the mechanism of SELinux's RBAC/MAC being in the kernel (and not terriby complex; yes, more complex than chroot, but perhaps not as complex as netfilter), but the policy in userland.
The other typical answer to exploits is firewalling: pray tell where that policy is enforced.
The best place is on a separate box from anything that it should be protecting.
Regardless, it's in the kernel on that box, if that box is a linux box. Lots of people use netfilter, and it has not been without its own bugs. And it's pretty complex, and in the kernel.
But kernel versus userspace isn't going to get settled here; this isn't the microkernel-versus-monolithic-kernel mailing list. CentOS has a monolithic kernel that has loaded SELinux code, even if you set SELinux to be off. Netfilter code is in the kernel, whether you setup any iptables or not. The kernel is complex; even if the feature (SELinux) isn't enabled bugs in that code could theoretically get you. So turning it OFF (which isn't really off) versus permissive isn't really much. Otherwise you need to compile a kernel without it completely.
I don't think we're going to find any profound truths on either side of this discussion; I simply have issue with the automatic 'old admin's tales' to turn it off. And I have issue with the mindset of answering a question on a problem an interested user/sysadmin has with SELinux with 'just turn it off. It breaks too many things.' That is wrongthink.
On Sat, 2005-11-19 at 15:02 -0500, Lamar Owen wrote:
If you look at the problem Windows NT and its children have is that it must have compatibility with the simpler, but less secure, Windows 3.0 Enhanced Mode kernel (as Win95, 98, and ME are all based off this code, which actually dates from late in the Windows 2.x 386 cycle).
Yes! The problem isn't the NT kernel, the _original_ NT/Win32 model isn't half bad. It's all the legacy APIs that have _tainted_ the NT/Win32 kernel. That's the problem.
Even being a UNIX and OS/2 administrator in 1993, I was a _huge_ fan of the Windows NT 3.1 design and release in 1994 (I saw the 3.1 Beta early on). When Gates gave the go-ahead to MS-DOS 7.0 in 1994, and the continuation of 386Enhanced Mode in MS-Windows 4.0 -- the bundled project "Chicago" turned product in Windows 95 -- that was the problem.
A probably that continued through Visual Studio 6.0, which was still being used internally by MS itself (let alone ISVs) just a few years ago.
The problem isn't the original RBAC/MAC complexity of NT. The problem is all the hacks, fixes and non-sense that has been built around it -- all the meanwhile _core_ "Chicago" subsystems have become a part of the heavilyi tainted NT/Win32 model. It was _never_ the original design.
RBAC/MAC does _nothing_ to hurt the simplicity of the UNIX piecemeal model. You need no further proof of this than other UNIX flavors like Solaris, who have added RBAC/MAC quite well. If Linux users refuse to adopt RBAC/MAC, then many of us will look at Solaris and other UNIX platforms increasingly.
On 19/11/05, Lamar Owen lowen@pari.edu wrote:
On Friday 18 November 2005 21:02, Preston Crawford wrote:
Your name is Lamar Odom?
:-)
No, see http://siusalukis.collegesports.com/sports/m-baskbl/mtt/owen_lamar01.html
See also:
http://www.nba.com/draft2003/profiles/McDonaldWill.html
:) I used to play too.
Will.
On Thursday 17 November 2005 18:12, Chris Mauritz wrote:
Lamar Owen wrote:
After reading through the various SELinux threads, I really became quite perturbed. I mean, really quite perturbed.
If you get perturbed over something so trivial, perhaps it's time to re-examine your priorities in life. 8-)
Security is not trivial. Or do you want your server or workstation to become a zombie in the next cyberattack? What if that attack is against a government? What if said government is your own and they decide to try you because you didn't prevent the attack (could happen; saw headlines last week about open wireless being outlawed somewhere)? What if you are found guilty, or, in a civil action, found personally liable because you consciously turned off a security feature that was known to prevent said attack from occurring (like, for instance, and allow everything outgoing firewall, perhaps).
Security is never trivial.
When I have to explain to an astronomer that that once in a lifetime radio followup to a gamma ray burst was wiped out because I was too lazy to properly secure the system, I won't think it was trivial.
The 'security is trivial' mindset is why we have Windows.
overhead/bloat on a system that doesn't really need it. Building a firewall? Building a hardened box that's going to be exposed to the net at a datacenter?
Didn't I mention Internet-facing in my post?
On Thursday 17 November 2005 18:12, Chris Mauritz wrote:
Lamar Owen wrote:
After reading through the various SELinux threads, I really became
quite
perturbed. I mean, really quite perturbed.
If you get perturbed over something so trivial, perhaps it's time to re-examine your priorities in life. 8-)
Security is not trivial. Or do you want your server or workstation to become
He never said security was trivial. He was speaking about the discussion and its relative weight. Why can't you separate it?
Security is never trivial.
Yes, we know.
When I have to explain to an astronomer that that once in a lifetime radio followup to a gamma ray burst was wiped out because I was too lazy to properly secure the system, I won't think it was trivial.
Preach ON!!!
The 'security is trivial' mindset is why we have Windows.
AMEN!!
Preston
Lamar Owen wrote:
On Thursday 17 November 2005 18:12, Chris Mauritz wrote:
Lamar Owen wrote:
After reading through the various SELinux threads, I really became quite perturbed. I mean, really quite perturbed.
If you get perturbed over something so trivial, perhaps it's time to re-examine your priorities in life. 8-)
Security is not trivial. Or do you want your server or workstation to become a zombie in the next cyberattack? What if that attack is against a government? What if said government is your own and they decide to try you because you didn't prevent the attack (could happen; saw headlines last week about open wireless being outlawed somewhere)? What if you are found guilty, or, in a civil action, found personally liable because you consciously turned off a security feature that was known to prevent said attack from occurring (like, for instance, and allow everything outgoing firewall, perhaps).
Security is never trivial.
Look, I don't think I intimated that security is/was trivial. Someone asked about a particular security tool. I commented that I didn't think that tool was worth the effort for many people. Many of us have been doing just fine with traditional hardening methods without installing kernel patches that actively break applications, add quite a bit of complexity, and is turned on by default...thus confusing people who don't know what SELinux is. Your attitude is that if you don't actively point every weapon in your arsenal at the world that you're somehow inept is just plain foolish and that SELinux is some magic panacea for securing a Linux box. It isn't.
I have been building and maintaining unix systems hanging off the net since the late 80's. To date, I have yet to have a machine compromised that I secured myself. So I'm somewhat confident in my ability to judge the relative risks/rewards of not using SELinux in many cases. You appear to feel differently. That's just dandy. You run your little corner of academia the way you want and I'll run my little corner of running dog capitalism the way I want. I have no idea why you feel the need to be so belligerent about it. *shrug*
And for you potential employers out there googling the net for any mention of my name....if you feel like Lamar, PLEASE just don't hire me. I couldn't bear the thought of some poor astrophysicist losing a day's worth of cosmic EMI/RFI due to my gross negligence. Find someone more worthy. 8-)
Cheers,
On Friday 18 November 2005 21:48, Chris Mauritz wrote:
Look, I don't think I intimated that security is/was trivial. Someone asked about a particular security tool. I commented that I didn't think that tool was worth the effort for many people.
Which didn't answer his question. Was the comment really necessary? Did it help anyone? Was it worth the effort?
don't know what SELinux is. Your attitude is that if you don't actively point every weapon in your arsenal at the world that you're somehow inept is just plain foolish and that SELinux is some magic panacea for securing a Linux box. It isn't.
You misunderstand my point. If you lay up the bazooka because 'it doesn't feel like a gun, man, it burns down anything behind you when you fire it, and wow, it is hard to use' then you are missing a part of your arsenal that you may very well need when that tank comes your way. Just because you've only seen infantry thus far doesn't mean that there is not a tank in your future.
I have been building and maintaining unix systems hanging off the net since the late 80's. To date, I have yet to have a machine compromised that I secured myself.
Maybe I'm wrong, but I think any admin needs to experience having their box cracked. It will produce the humbleness necessary to the trade, because overconfidence is dangerous.
appear to feel differently. That's just dandy. You run your little corner of academia the way you want and I'll run my little corner of running dog capitalism the way I want. I have no idea why you feel the need to be so belligerent about it. *shrug*
The belligerence happened quite a ways before, during the first thread where totally unnecessary and useless answers were being hurled at the OP. But I'm more sick and tired of so much belligerence in general. No, more gripe wasn't the correct answer. But what is?
I couldn't bear the thought of some poor astrophysicist losing a day's worth of cosmic EMI/RFI due to my gross negligence. Find someone more worthy. 8-)
Good laugh... :-) Needed that laugh.
As the health and security of that data is my bread and butter (and my wife's, and my son's, and my three daughters') I do tend to be protective of it, as nearly random as it is (all 20TB per day of it). But is sure is cool to work with.
On Fri, 2005-11-18 at 22:42, Lamar Owen wrote:
Maybe I'm wrong, but I think any admin needs to experience having their box cracked. It will produce the humbleness necessary to the trade, because overconfidence is dangerous.
Yes, but when the box gets cracked _because_ they are using the latest new thing their distribution added under the guise of increased security, as happened with ssh a while back, it also produces the attitude that new stuff should soak a long, long while in a distribution like fedora before going onto production boxes. You want to at least wait until the surprises stop - and I take the flurry of reports of broken apps at every update as an indication that they haven't stopped yet.
Your analogy to a weapon was a good one. When the experts tuning the distribution still can't keep it from blowing up in peoples's faces some of the time, normal people should keep their distance. When the fedora and Centos lists go several months without a mysterious app failure caused by SELinux it will be time to reconsider.
On Sat, 2005-11-19 at 10:41 -0600, Les Mikesell wrote:
On Fri, 2005-11-18 at 22:42, Lamar Owen wrote:
Maybe I'm wrong, but I think any admin needs to experience having their box cracked. It will produce the humbleness necessary to the trade, because overconfidence is dangerous.
Yes, but when the box gets cracked _because_ they are using the latest new thing their distribution added under the guise of increased security, as happened with ssh a while back, it also produces the attitude that new stuff should soak a long, long while in a distribution like fedora before going onto production boxes. You want to at least wait until the surprises stop - and I take the flurry of reports of broken apps at every update as an indication that they haven't stopped yet.
Your analogy to a weapon was a good one. When the experts tuning the distribution still can't keep it from blowing up in peoples's faces some of the time, normal people should keep their distance. When the fedora and Centos lists go several months without a mysterious app failure caused by SELinux it will be time to reconsider.
---- I hope that you realize that only those who routinely disable selinux would actually make that statement.
I actually am on the same fedora and centos lists as you and I don't see 'a flurry of reports of broken apps at every update' - perhaps your characterization is shaded by your desire to believe that something in selinux is broken...it isn't. There is only a lack of knowledgeable people advising people how to fix their issues. The only barriers to using selinux that I see is that people have to figure out whether they need to change file contexts, relabel certain files or simply change policy and there are simple tools to use for all of those circumstances. I am learning them and I am not that smart.
As for your comment 'normal people should keep their distance' - that sounds like like advice from someone who has made an uninformed decision and wants others to follow his uninformed lead. If you employed selinux everywhere and suggested to others that they not do so you might have some credibility.
Of course when the 2.4 kernel was released, there were a number of people who advocated continuing to use ipchains because they understood that and didn't understand netfilter/iptables and did a similar disservice to others by suggesting that other users followed this lead.
I haven't disabled selinux on any system that I setup/maintain/operate whether it is clients RHEL/CentOS or my own fedora desktops. The only issue that stopped anything was update of mysql and a relabel fixed that...one command - done. Of course this list was of no help because everyone was drawn to the debate rather than the solution.
I do occasionally have to deal with issues...such as those caused by upgrade from CentOS 4.1 to 4.2 but they were not difficult...and the solution to them was clearly not offered by those who think that they are providing value by suggesting that I simply turn it off.
I also occasionally have issues with things like BIND, LDAP, cyrus-imapd etc. and rather than turn them off, I actually take the time to discover the nature of the problem and then fix it. SELinux is not different.
Craig
On Sat, 2005-11-19 at 10:41 -0600, Les Mikesell wrote:
Yes, but when the box gets cracked _because_ they are using the latest new thing their distribution added under the guise of increased security, as happened with ssh a while back, ... cut ...
For the last time, let's _stop_ comparing SELinux to services! And that includes services that "escalate privilege" like suexec. SELinux does _not_ grant new privilege, it _only_ removes them.
Compare SELinux to NetFilter.
NetFilter removes access from the IP stack. SELinux removes access from normal kernel authorization.
Yes, you can write an incorrect IPTables rule and grant more access than a correctly written one. But you can_not_ write an IPTables rule that grants more access than if NetFilter is disabled!
Under the same token, you can write incorrect SELinux rules that grant more access than a correctly written one. But you can_not_ write an SELinux rule that grants more access than if SELinux is disabled!
The only possible case where SELinux/NetFilter might be a buffer overflow in the code. That has _nothing_ to do with rule writing, but the existence in the kernel itself! That's it! Otherwise, there is virtually _no_ way any SELinux/NetFilter functionality can compromise a system versus being disabled!
If you don't understand these _facts_ by now, then you really don't understand how SELinux or NetFilter work compared to traditional security mechanisms in user-space. They _never_ grant new privileges, only _remove_ them -- and not as a service, but at the kernel's core.
SELinux/NetFilter in the kernel are like seat belts in a car.
They are a major pest in your normal, daily activities, and they will _never_ get better. At the most we can devise newer and less intrusive ways to restrain you over time, but they will _always_ be a "bug."
There is virtually no way they can introduce more liability to your overall safety, unless you really nitpick on minor things. E.g., there is a chance you _could_ die if you drive into a retention pond and in the 1-3 seconds it takes you remove your seat belt, those were the 1-3 seconds you needed to reach the surface before you became unconscious.
To make that argument with regards to retention ponds about seat belts is to make the same argument that you won't enable SELinux/NetFilter (e.g., IPTables) default rules because they could have a buffer overflow somewhere. If you're worried about buffer overflows, then build a kernel without SELinux, NetFilter and anything else that could potentially have buffer overflows!
Instead of continuing that rather pathetic viewpoint (and I'm sorry, that's what it is), just admit you don't want to be constrained by seat belts.
Some you seem to be drowning in the "complex=secure" scenario.
SELinux adds complexity, the biggest dangers in computer hacking come from within your own network.
90% of hacking jobs are in house as the statistics show.
SELinux makes security complex and bloat like, the same thing that makes Windows insecure, this makes the admin job harder, which will lead to mistakes, which will make it hard to find holes, which will inevitably lead to a less secure system.... QED.
Perhaps all of you that _LOVE_ SElinux so much should branch off to a new flavour of Linux,
I propose that you name it BloatOS,
Just keep it well away from me.
My boxes have SELinux=disabled on all of them (thats a big number by the way).
I don't need it, those sysadmins who feel they need to use, sure go ahead and use it, but please don't take the morale high ground saying using it is definately better and more secure, because I find that kind of talk irritating because it is so wrong.
One thing is for sure, SELinux slows the box down, which perhaps you could start arguing that "aah yes the box is so much slower now, it wil take a hacker longer to get in - hey SElinux really is secure for that reason alone" -- ROTFLOL....
I think you should rename this thread BloatOS.
You could then write shell script called "unbloat" or "speedup"
I propose it contains
rpm -e libselinux-1.19.1-7 selinux-policy-targeted-1.17.30-2.110 libselinux-devel-1.19.1-7
Maybe that too has some marketing mileage, you could sell this script as a box performance enhancer,
LOL
Les Mikesell wrote:
On Fri, 2005-11-18 at 22:42, Lamar Owen wrote:
Maybe I'm wrong, but I think any admin needs to experience having their box cracked. It will produce the humbleness necessary to the trade, because overconfidence is dangerous.
Yes, but when the box gets cracked _because_ they are using the latest new thing their distribution added under the guise of increased security, as happened with ssh a while back, it also produces the attitude that new stuff should soak a long, long while in a distribution like fedora before going onto production boxes. You want to at least wait until the surprises stop - and I take the flurry of reports of broken apps at every update as an indication that they haven't stopped yet.
Your analogy to a weapon was a good one. When the experts tuning the distribution still can't keep it from blowing up in peoples's faces some of the time, normal people should keep their distance. When the fedora and Centos lists go several months without a mysterious app failure caused by SELinux it will be time to reconsider.
On 11/25/05, Peter Farrow peter@farrows.org wrote:
Perhaps all of you that _LOVE_ SElinux so much should branch off to a new flavour of Linux,
I propose that you name it BloatOS,
Just keep it well away from me.
Excellent work, Peter!
I've been deleting most of the posts in this thread unread, but I'm glad I read this one. This one's a keeper.
-- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
Gentlemen,
CLOSE THIS THREAD FOR THE SAKE OF GOD!
OK, YOU ARE THE SMARTEST GUY BECAUSE YOU DON'T USE SELINUX AND WE ARE THE DUMBS WHO ARE ABLE TO USE IT, OK?
DON'T WRITE MORE EMAILS ON THE TOPIC! I FED UP WITH THIS THREAD.
Ago
On Sat, 2005-11-26 at 00:31 +0000, Lance Davis wrote:
On Sat, 26 Nov 2005, Deim [iso-8859-2] Ágoston wrote:
Gentlemen,
CLOSE THIS THREAD FOR THE SAKE OF GOD!
Please dont use religion on this mailing list :)
?? You have not observed that most of the discussions on this list are in fact religious in nature? How else to justify the tones, intolerance, "religious zeal" in espousing one's own position as "the one true way", ...
Anyway Agoston's was better in that he obviously recognizes that the author of his post was not God, which is difficult to ascertain in many of the others we've seen. >:-O
Lance
Bill
Always try my best!
P :-)
Collins Richey wrote:
On 11/25/05, Peter Farrow peter@farrows.org wrote:
Perhaps all of you that _LOVE_ SElinux so much should branch off to a new flavour of Linux,
I propose that you name it BloatOS,
Just keep it well away from me.
Excellent work, Peter!
I've been deleting most of the posts in this thread unread, but I'm glad I read this one. This one's a keeper.
-- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Peter Farrow wrote:
Some you seem to be drowning in the "complex=secure" scenario. SELinux adds complexity, the biggest dangers in computer hacking come from within your own network. 90% of hacking jobs are in house as the statistics show.
And SELinux's _main_ design is to combating people who have _some_ privileges to the system! That's the primary purpose of RBAC/MAC! As someone who has spent half of his career security banks and defense systems, please, _please_ stop this! SELinux _massively_ improves internal security.
So why did this come up, yet again? Why does this have to continue? Especially since the upstream provider sets the defaults, and these will NOT change in SELinux!
SELinux makes security complex and bloat like, the same thing that makes Windows insecure, this makes the admin job harder, which will lead to mistakes, which will make it hard to find holes, which will inevitably lead to a less secure system.... QED.
As I pointed out before, NT's based RBAC/MAC does _not_ cause its security issues. In fact, it's quite a good model to follow! The problem is 99% of the Windows applications, including various things adopted into NT for "Chicago" compatibility that have caused this issue.
Why oh why did this come up again? These defaults will NOT change!
Peter Farrow also wrote:
Perhaps all of you that _LOVE_ SElinux so much should branch off to a new flavour of Linux, I propose that you name it BloatOS, Just keep it well away from me.
Collins Richey wrote:
Excellent work, Peter! I've been deleting most of the posts in this thread unread, but I'm glad I read this one. This one's a keeper.
Instead of renaming the distro, maybe we should have a new list entitled, "What we want to bitch about this week, but not stop and take the time to understand and possible resolve?!"
It's pretty sad when all people like myself (and I'm not the only one) wish to do is correct technical inaccuracies, _not_ to stop and shove anything down anyone's throat. You don't have to use what is included or suggested, but not everything is "broken" or "not as good as distro X." Why don't we just start a thread on politics here -- because it would be able to it would provide the same level of resolution for "world peace" as it would for Red Hat Enterprise Linux defaults.
I.e., *NONE*! ;->
_Nothing_ that has come out of e-mails has been "you must do this." It's always been, "Have you considered this? Do you understand what this does?" It's easy to bitch and moan about something when you don't understand it -- and far worse yet -- it does _nothing_ because you don't understand why things are the way they are (and no one can help you)! But these are the defaults. Live with it however you want to!
But don't make CentOS a forum to expose your constant complaints of something you don't want to deal with. Stop pretending you even remotely know how things like SELinux are "bad" (I mean, how many different arguments are people going to make 2, 3 or even 4 times over?!) Or how distribution of CentOS+DAG has a purely "mechanical" issue? Or how YUM could be better? Etc...
Craig White wrote:
I'm not entirely sure why you decided to pick up this topic by replying to a message that is a week old.
I honestly thing some people just have to bitch about something they don't want to deal with. They can't step back and recognize why something is designed or why something works the way it does. They just want it to "work my way dammit!"
Personally, I would have thought you to be smart enough to let the thread die since you used it to insult one of the CentOS developers.
In case some of you aren't "getting it," Craig puts it out right there!
You say you thank the CentOS developers for their hard work ... "But this" and then there's another "But that". And most of these "but"s aren't really about giving _any_ care to what decisions are made with CentOS, but just bitching about how you think it should work.
And in the overwhelming majority of cases, it's something these same people don't know about or understand. All I've tried to do, like a broken record, is ask people to stop and understand things, and I've been very futile in my attempts at times. I honestly give up on this, as well as the
Apparently you decided to revive the thread just to insult those of us that are actually trying to intelligently apply the security features adopted by the upstream provider. Personally, I find you offensive.
I'm not offended directly. I rarely get offended. Someone has to call my employer or tell the FBI that I hacked their server to offend me (and no one has stooped to that level here ;-).
What I find _indirectly_ offensive is how much the CentOS team is bothered by these constant inquiries on things that WILL *NOT* CHANGE! Let me say that again ... these things WILL *NOT* CHANGE! That's why it's *NOT* about finding solutions, but just "bitching." Especially when the same "round robin, blind analysis" comes up over and over and over on RBAC/MAC, [re]distribution, etc...
On Fri, 2005-11-25 at 23:09 +0000, Peter Farrow wrote:
Some you seem to be drowning in the "complex=secure" scenario.
SELinux adds complexity, the biggest dangers in computer hacking come from within your own network.
90% of hacking jobs are in house as the statistics show.
SELinux makes security complex and bloat like, the same thing that makes Windows insecure, this makes the admin job harder, which will lead to mistakes, which will make it hard to find holes, which will inevitably lead to a less secure system.... QED.
Perhaps all of you that _LOVE_ SElinux so much should branch off to a new flavour of Linux,
I propose that you name it BloatOS,
Just keep it well away from me.
My boxes have SELinux=disabled on all of them (thats a big number by the way).
I don't need it, those sysadmins who feel they need to use, sure go ahead and use it, but please don't take the morale high ground saying using it is definately better and more secure, because I find that kind of talk irritating because it is so wrong.
One thing is for sure, SELinux slows the box down, which perhaps you could start arguing that "aah yes the box is so much slower now, it wil take a hacker longer to get in - hey SElinux really is secure for that reason alone" -- ROTFLOL....
I think you should rename this thread BloatOS.
You could then write shell script called "unbloat" or "speedup"
I propose it contains
rpm -e libselinux-1.19.1-7 selinux-policy-targeted-1.17.30-2.110 libselinux-devel-1.19.1-7
Maybe that too has some marketing mileage, you could sell this script as a box performance enhancer,
LOL
---- I'm not entirely sure why you decided to pick up this topic by replying to a message that is a week old. Personally, I would have thought you to be smart enough to let the thread die since you used it to insult one of the CentOS developers. Apparently you decided to revive the thread just to insult those of us that are actually trying to intelligently apply the security features adopted by the upstream provider. Personally, I find you offensive.
The fact that you think removing those files would speed up anything on your computer is a complete demonstration of how little you understand about selinux.
The fact that you cannot see how selinux would help protect you from 'inhouse hacks' is further evidence of how little you understand about selinux.
Of course you can disable it. If you want a distribution without it altogether, you would have to go elsewhere as the upstream provider believes in it, includes it and that is that.
I was holding back on some interesting links about selinux not wishing to bring the topic up on this list but since the topic was already brought up...(of course, this is only going to be of interest to those who actually are concerned with security of their boxes as opposed to posturing for the benefit of their ego)
1.) http://www.linuxsecurity.com/content/view/120567/49/
2.) http://www.linuxsecurity.com/content/view/120622/49/
3.) http://www.linuxsecurity.com/content/view/120700/49/
Craig
Priceless :) You just made it to my email quote of the week wall :)
*laugh*
On Nov 25, 2005, at 3:09 PM, Peter Farrow wrote:
Some you seem to be drowning in the "complex=secure" scenario.
SELinux adds complexity, the biggest dangers in computer hacking come from within your own network.
90% of hacking jobs are in house as the statistics show.
SELinux makes security complex and bloat like, the same thing that makes Windows insecure, this makes the admin job harder, which will lead to mistakes, which will make it hard to find holes, which will inevitably lead to a less secure system.... QED.
Perhaps all of you that _LOVE_ SElinux so much should branch off to a new flavour of Linux,
I propose that you name it BloatOS,
Just keep it well away from me.
My boxes have SELinux=disabled on all of them (thats a big number by the way).
I don't need it, those sysadmins who feel they need to use, sure go ahead and use it, but please don't take the morale high ground saying using it is definately better and more secure, because I find that kind of talk irritating because it is so wrong.
One thing is for sure, SELinux slows the box down, which perhaps you could start arguing that "aah yes the box is so much slower now, it wil take a hacker longer to get in - hey SElinux really is secure for that reason alone" -- ROTFLOL....
I think you should rename this thread BloatOS.
You could then write shell script called "unbloat" or "speedup"
I propose it contains
rpm -e libselinux-1.19.1-7 selinux-policy-targeted-1.17.30-2.110 libselinux-devel-1.19.1-7
Maybe that too has some marketing mileage, you could sell this script as a box performance enhancer,
LOL
Les Mikesell wrote:
On Fri, 2005-11-18 at 22:42, Lamar Owen wrote:
Maybe I'm wrong, but I think any admin needs to experience having their box cracked. It will produce the humbleness necessary to the trade, because overconfidence is dangerous.
Yes, but when the box gets cracked _because_ they are using the latest new thing their distribution added under the guise of increased security, as happened with ssh a while back, it also produces the attitude that new stuff should soak a long, long while in a distribution like fedora before going onto production boxes. You want to at least wait until the surprises stop - and I take the flurry of reports of broken apps at every update as an indication that they haven't stopped yet.
Your analogy to a weapon was a good one. When the experts tuning the distribution still can't keep it from blowing up in peoples's faces some of the time, normal people should keep their distance. When the fedora and Centos lists go several months without a mysterious app failure caused by SELinux it will be time to reconsider.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Elizabeth Palomino liz@groupee.com Sr. Performance Engineer Groupee (206)283-5999 Infopop is now Groupee... Same Company, New Name
-
Bryan J. Smith -
Chris Mauritz -
Collins Richey -
Craig White -
Deim Ágoston -
Elizabeth Palomino -
Lamar Owen -
Lance Davis -
Les Mikesell -
Paul Heinlein -
Peter Farrow -
Preston Crawford -
Ron Jones -
Will McDonald -
William L. Maltby