On Fri, 2005-11-18 at 19:11, Lamar Owen wrote: > > Well, it may or may not be true. It is certainly well-intentioned, but > > we are talking about bugs and unexpected behavior here which by > > definition aren't predictable. > > Les, let me make a statistical contrast here. Standard run of the mill bugs > are stochastic in nature (that is, unpredictable) and thus will in aggregate > fall on a Gaussian distribution. Black hat activities are not stochastic, > and a predictably bad for you. I think I'd rather take my chances with bugs. But you have to have a bug to exploit in the first place. Otherwise there is nothing wrong with the standard unix permission concepts that have served us well for 30 years. The black hat activities can only exploit existing bugs and adding new code that no one understands may not be the way to reduce bugs. > > likely, by making normal operations more difficult, you set up > > the authorized users to need more outside help and more chances for > > social engineering efforts to steal their credentials. > > That's where properly configuring the policies becomes critical. You need to > profile what constitutes 'normal' first, then set your policies to allow the > normal activities without intervention. The abnormal is what gets blocked, > and hopefully at least is what the worm/black hat is trying to do. If you are starting from scratch building a new service you can do that. If you've inherited 30 years worth of existing stuff that relies on permissions being what the filesystem says they are, then you are going to be spending an enormous amount of time trying to fix something that wasn't broken. > Let me clarify my position on this, as I seem to not have conveyed my meaning > quite as clearly as I intended. My problem is not with 'turning SELinux off' > but with the attitude that one should always turn SELinux off. If you have a > valid reason for turning it off (or setting it to permissive and setting the > syslog options correctly) then do it; but don't assume that that is the Right > Thing for Everybody All the Time. It's no fun arguing with someone who is being reasonable... But compare this to a few years back when distributions added ssh because of its security advantages over telnet - and in doing so introduced the means that many systems, including some of mine, were exploited using bugs in the new code. Following someone else's advice about best practices doesn't always make your system more secure, even when the theory sounds right. -- Les Mikesell lesmikesell at gmail.com