1: e-mail is a people skill, you affect people with it. The value of your presentation rises or falls with your skill at presentation. 2: My embedded headless linux targets live in isolated networks, even relative to other computer or network equipment at the target site. At times, the nearest land is 2 miles straight down (ocean floor). 3: These targets are also without anything resembling a linux-aware operator and (ipso facto) must generate NO mail and self-limiting logs of a "usually ignored' type.
from the above, SELinux offers me *nothing* I need and costs me something for which there is no reward.
Brian Brunner brian.t.brunner@gai-tronics.com (610)796-5838
thebs413@earthlink.net 11/17/05 06:38PM >>>
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.
******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager.
This footnote also confirms that this email message has been swept for the presence of computer viruses.
www.hubbell.com - Hubbell Incorporated
On Fri, 2005-11-18 at 05:43 -0800, Brian T. Brunner wrote:
1: e-mail is a people skill, you affect people with it. The value of your presentation rises or falls with your skill at presentation. 2: My embedded headless linux targets live in isolated networks, even relative to other computer or network equipment at the target site. At times, the nearest land is 2 miles straight down (ocean floor). 3: These targets are also without anything resembling a linux-aware operator and (ipso facto) must generate NO mail and self-limiting logs of a "usually ignored' type.
from the above, SELinux offers me *nothing* I need and costs me something for which there is no reward.
---- I would bet a dollar that there is a CentOS server in your office where
grep 'SELinux=disabled' /etc/selinux/config == true
that notwithstanding, I am sure you realize that considering your premise of usage stated above, that a strong argument could be made that it is an ideal candidate for the protections of SELinux.
Of course, you are the master of your systems and you are in control over the decision on what to employ and then who is to say that you are wrong in your assessment.
As for email skills, there are likely a lot of readers of this list that see the people who frequently post and probably put a lot of trust in their opinions and someone who unwittingly has this position and says - just disable it - probably does a disservice to those who might only be looking for justification to turn off something that they don't understand. Email skills can also encompass the ability to recognize the difference between expressing an opinion for one's own peculiar usage as it relates to the broader base as a whole and make the distinction clear.
Craig
On Fri, 2005-11-18 at 07:04 -0700, Craig White wrote:
that notwithstanding, I am sure you realize that considering your premise of usage stated above, that a strong argument could be made that it is an ideal candidate for the protections of SELinux.
Ditto. That's what keeps getting to me.
It would be one thing if he said, "I don't want to deal with SELinux." I've _always_ respected his view on that. I don't expect people to deal with RBAC/MAC if they don't want to (although as a few have stated, that might affect their consideration by a prospective client/employer -- but _no_one_ is in an interview here, so don't read too much into it ;-).
Yet according to him, people like you and I who are implementing SELinux in the same environments, we're doing it all-for-not! That's simply not true! And I agree, remote systems are _ideal_ for RBAC/MAC.
And if I have to implement a change (even updates), something that might be affected by _any_ control -- I first do it with systems near to me. I test those changes locally, and then I roll out those change remotely (be it remote update, or a box exchange if warranted). That's just good configuration management. It has nothing to do with RBAC/MAC!
I don't ship something with RBAC/MAC that doesn't work. But that doesn't mean I disable RBAC/MAC _instead_ of making it work. And it doesn't mean that _only_ RBAC/MAC would affect a change in the field. That's why I don't make "on-the-spot" changes in the field! That violates configuration management principles. ;->
Or do I just not know what I'm talking about?
Email skills can also encompass the ability to recognize the difference between expressing an opinion for one's own peculiar usage as it relates to the broader base as a whole and make the distinction clear.
I suck at e-mail. I am not always clear. I admit this. In fact, my biggest problem with trying to hold a conversation in e-mail has to do with the fact that I almost approach it _too_much_ like a "real conversation."
I write like I would speak on the phone or in-person -- including sarcasm, tone-based wit/effect (never comes through in e-mail, I forget that), etc...
After 16 years of e-mail on the Internet, I've learned 1 thing.
It's better for me to avoid conversation and story telling in e-mail. Unfortunately, we all don't have each other's phone numbers. I've tried to use blogs to reduce my story telling, but I still do it.
So in a professional environment, I _avoid_ it. If you have a weakness, you _avoid_ it. I also do it because a phone conversation is typically better and quicker, or a formal tech doc would do far better, with less chance for errors.
Especially since I'm a regular author of various columns and a contributor to a series of books (read the _next_ sentence before you think I'm on an "ego" trip please ;-). By my very "programmed" nature, I'm verbose to an extreme -- unassuming whether you might know what I'm talking about or not, so I start almost "newbie'ish" sometimes because the audience of an article or book _varies_ in knowledge.
But in a professional environment, I _avoid_ e-mail. And I expect that of others. And I _know_ most of my clients and/or supervisors don't like it when any consultant or employee contacts them in e-mail -- they want a voice or a presence.
So far, in a professional environment, I have been complemented by clients because I do _not_ hold conversations in e-mail. I call them up. I write them up some sectionalized documentation (which I can crank out in no time!) instead of crappy e-mail.
If they _only_knew_ the reason I avoid e-mail is because I really suck at holding conversations in it. Actually, so _do_ know. And to them, it's not an issue because I _never_ use it for business.
On Fri, 2005-11-18 at 09:55 -0500, Mark Belanger wrote:
Bryan J. Smith wrote:
But in a professional environment, I _avoid_ e-mail.
Boy I'd hate to see the volume of mail you'd generate if you *weren't* avoiding email. :)
---- nobody in the workgroup would have any time left each day.
;-)
Craig
On Fri, 2005-11-18 at 07:58 -0700, Craig White wrote:
nobody in the workgroup would have any time left each day. ;-)
I wish you guys would just get over some of your fixations on how I post and leave it to the people who _do_ care for it. What you may or may not like does _not_ represent what some people -- especially the people who _are_ asking the questions I'm answering, even if they are in the "minority."
Talk about egos! Geez. At least I have some humility, and I keep thinking about those people, and not you guys.
This thread is getting personal now, so it's time to chill.
I suggest if you want to post on this subject, put it off for one hour minimum, and then decide again.
Tony Schreiner
On Fri, 2005-11-18 at 10:16 -0500, Tony Schreiner wrote:
This thread is getting personal now, so it's time to chill.
In any thread where two or more people are arguing back and forth (like Craig and Brian B.) are, there is always one way to get them to agree ...
Talk about me. ;->
Especially after I'm humble enough to admit my own failures.
On Fri, 2005-11-18 at 09:28 -0600, Bryan J. Smith wrote:
On Fri, 2005-11-18 at 10:16 -0500, Tony Schreiner wrote:
This thread is getting personal now, so it's time to chill.
In any thread where two or more people are arguing back and forth (like Craig and Brian B.) are, there is always one way to get them to agree ...
Talk about me. ;->
Especially after I'm humble enough to admit my own failures.
---- hey - this was a pretty witty post
;-)
Craig
Craig White wrote:
On Fri, 2005-11-18 at 09:55 -0500, Mark Belanger wrote:
Bryan J. Smith wrote:
But in a professional environment, I _avoid_ e-mail.
Boy I'd hate to see the volume of mail you'd generate if you *weren't* avoiding email. :)
nobody in the workgroup would have any time left each day.
;-)
You'd have to buy time on Blue Gene just to run your mail filter. 8-)
Chris Mauritz chrism@imntv.com wrote:
You'd have to buy time on Blue Gene just to run your mail filter. 8-)
I might as well fire up UT2004 and all of you on!
Stats ...
Team BS Team Scroll [Red Face] [Blue Gene] ---------------- ------------------ BS 100 Brianna 0 Lessy 0 Chrissy 0
On Fri, 2005-11-18 at 08:53 -0600, Bryan J. Smith wrote:
If they _only_knew_ the reason I avoid e-mail is because I really suck at holding conversations in it. Actually, so _do_ know. And to them, it's not an issue because I _never_ use it for business.
---- if it is true that brevity is the form of wit, you need to demonstrate more wit or give readers more credit for what they should already know.
Your posts are excessively verbose and since the typical reader isn't going to plough through each and every word unless it is absolutely necessary, your words lose power simply because of the sheer volume.
Craig
On Fri, 2005-11-18 at 07:57 -0700, Craig White wrote:
if it is true that brevity is the form of wit, you need to demonstrate more wit
Agreed.
or give readers more credit for what they should already know.
That's the problem. You think I'm not giving them credit for what they already know. And some take it as an insult. Why is that?
Can't they be considerate of the fact that maybe not everyone has used something before? That they weren't familiar with something I just explained?
It's one thing if I answer someone's question who is obviously familiar with something already, and I recover the basics. I can see how they would take that as an insult, and I _do_ need to avoid that.
But when I answer someone who has stated they are not familiar with something, and I cover it with verbosity and completeness, only to see _others_ jump in and bitch about it ...
Who is the "problem" then?!
That's not on me in that case. Yes, it's verbose. Yes, the majority of the list might not want to hear it. Yes, some might take it as insulting ...
But *WHO* did I write it for? Think about it! ;->
Several times a week I get an off-list message from people tell me how they appreciated my _detailed_ answer -- especially when it already answered 2-3 follow-ups they were about to ask. And some just _avoid_ the list from then on, and ask me questions directly.
And there are _several_ of those people on this list
They just contact me off-list because of the "jump on Bryan" non-sense! Geez, do some people every think that when I answer some questions, there _are_ people who like the verbosity?! It is _not_ warranted sometimes -- and I can't believe you wouldn't realize that there _are_ many cases this is true!
Your posts are excessively verbose and since the typical reader isn't going to plough through each and every word unless it is absolutely necessary, your words lose power simply because of the sheer volume.
To the "seasoned" administrators, yes. But to some of the people I'm answering ... think again!
Consider _who_ I am answering _before_ you think such. Because I am _not_ writing it for the list, I'm writing it for the 1 person who asked the question.
Which is why I just answer people off-list sometimes, because some people have real "ego" problems and _always_ take what I say as an insult to the list. That's _not_ on me when I'm answering someone who _does_ appreciate the verbosity.
On Fri, 2005-11-18 at 08:53, Bryan J. Smith wrote:
Yet according to him, people like you and I who are implementing SELinux in the same environments, we're doing it all-for-not! That's simply not true! And I agree, remote systems are _ideal_ for RBAC/MAC.
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. You may, by adding extra layers of security, protect against some flaw that will turn up even in the simple, well understood existing programming. Or, you may, by adding extra layers of complexity and less-tested code, introduce new vulnerabilities that no one understands yet. And even more 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.
Les Mikesell lesmikesell@gmail.com 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. You
may,
by adding extra layers of security, protect against some
flaw
that will turn up even in the simple, well understood
existing
programming.
That's the idea behind RBAC/MAC.
Or, you may, by adding extra layers of complexity and less-tested code, introduce new vulnerabilities that no one understands yet.
This is _far_ less likely. Why? RBAC/MAC doesn't "grant" access by default. It removes it! RBAC/MAC is _not_ a "service" -- it's a kernel subsystem that removes access.
It's like saying the Linux NetFilter (which is used by IPTables for those that don't know) introduces vunerabilities into the IP stack. NetFilter only _denies_ access, it does _not_ allow any "new" access! @-p
That's something that people keep missing here. RBAC/MAC is _not_ a "service" anymor ethan NetFilter is! Sure, you can screw up your RBAC/MAC rules just like IPTables rules, but not any more than having _no_ rules!
[ Please, please tell me some lightbulbs out there went off? ;-]
And even more 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.
Ahhh, the chronic "not supportable" issue. Yes, well in my biased experience, if you need such controls, they are not optional. But I've lost those arguments before ...
On bank networks no less!
I keep hearing about alleged "bugs" and "holes" and possible "exploits" for SELinux. Please, _please_ understand that SELinux is like NetFilter, a supervisory kernel subsystem that _only_ takes _away_ access (does _not_ grant more).
On Fri, 2005-11-18 at 10:41 -0800, Bryan J. Smith wrote:
This is _far_ less likely. Why? RBAC/MAC doesn't "grant" access by default. It removes it! RBAC/MAC is _not_ a "service" -- it's a kernel subsystem that removes access.
It's like saying the Linux NetFilter (which is used by IPTables for those that don't know) introduces vunerabilities into the IP stack. NetFilter only _denies_ access, it does _not_ allow any "new" access! @-p
That's something that people keep missing here. RBAC/MAC is _not_ a "service" anymor ethan NetFilter is! Sure, you can screw up your RBAC/MAC rules just like IPTables rules, but not any more than having _no_ rules!
[ Please, please tell me some lightbulbs out there went off? ;-]
Now no more "SELinux will open up more holes" non-sense! In the absolute worst case, you write an incorrect SELinux rule, just like you might accidentally write an incorrect IPTables rule. In _either_ case you do _not_ get "more holes" than if you had SELinux off, just like you do _not_ get "more holes" if you had _no_ IPTables rules. ;->
[ Again, please tell me some lightbulbs went off?! ]
At this point, I could _care_less_ if some of you use SELinux out there. But please stop with the technically inaccurate statements that SELinux bugs could cause more holes than when SELinux disabled. It's like saying the wrong IPTables rule can cause more holes than with NetFilter disabled and no IPTables rules at all (allow everything in/out)!
On Sat, 2005-11-19 at 06:50, Bryan J. Smith wrote:
I keep hearing about alleged "bugs" and "holes" and possible "exploits" for SELinux. Please, _please_ understand that SELinux is like NetFilter, a supervisory kernel subsystem that _only_ takes _away_ access (does _not_ grant more).
That's what it is supposed to do. We are talking about bugs and unexpected behavior here. Are you claiming that a bug in kernel code can't have security implications?
Now no more "SELinux will open up more holes" non-sense! In the absolute worst case, you write an incorrect SELinux rule, just like you might accidentally write an incorrect IPTables rule. In _either_ case you do _not_ get "more holes" than if you had SELinux off, just like you do _not_ get "more holes" if you had _no_ IPTables rules. ;->
No, the worst case would be more like the bug affecting setuid handling fixed in kernel 2.2.16. How many years did it take to find that one?
On Sat, 2005-11-19 at 12:03 -0600, Les Mikesell wrote:
No, the worst case would be more like the bug affecting setuid handling fixed in kernel 2.2.16. How many years did it take to find that one?
Once again, setuid _grants_ privilege! Please think that through! If you disable setuid, you _increase_ security, because you _remove_ access.
You don't _remove_ access when you disable SELinux. Just like you don't _remove_ access when you disable NetFilter. ;->
On Friday 18 November 2005 12:47, Les Mikesell 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.
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.
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.
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.
On Friday 18 November 2005 21:54, Les Mikesell wrote:
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.
No, it may not be a reduction in the net number of bugs. I'll not argue that point. I will say that I do think the base premise of one superuser is a Wrong Thing, and I think properly implemented roles and mandatory access controls are the right direction for adding yet another layer.
If I have a flat tire, and have five patches to fix the tire, but each patch has a hole in it, the likelihood is that if I apply all five patches the holes won't line up and I can make it home on the tire. Yes, it is possible that all five holes will line up; but it is less likely than with one patch on the tire. And all the patches have holes; there is always one more bug in every program, regardless of age and experience.
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.
And this is the sort of thing the Fedora and Red Hat developers are doing now. This is why RHEL has a targeted and not a blanket enforcing policy. No, it is not perfect. Neither are the other security features in recent Red Hat releases, some of which interacted badly with some programs I use daily (CrossOver Office, for one, didn't like execshield, but it was Wine that was broken, not execshield).
It's no fun arguing with someone who is being reasonable...
Judging from some others' replies, not all share your opinion; that's ok. I try to be reasonable, but I also tend to expect others to be reasonable, and tend to get nervy with those who are unreasonable. And I am not always successful at being reasonable (just ask my kids). :-)
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.
In theory, there is no difference between theory and practice. In practice, there is.
I wasn't impacted by the ssh holes, since I had two more layers above that preventing any ssh sessions from untrusted IP's. Of course, I patched when the patches came out, because I know that no firewall is perfect. But the holes don't usually line up.
Layers, layers, layers. Winter is coming upon us, and the advice is always to dress in layers. Sound advice, both for clothing and for security. The Internet Blizzard of malware is upon us; weather the storm with layers. Yeah, that woolen union suit might itch, but it sure is warm.
On Fri, 2005-11-18 at 05:43 -0800, Brian T. Brunner wrote:
1: e-mail is a people skill, you affect people with it. The value of your presentation rises or falls with your skill at presentation.
In environments like this, communication over e-mail is not optional. Otherwise we'd all have travel and phone bills that would be counter- productive. ;->
[ NOTE: Although I _do_ ask for phone numbers and call people at times when something is difficult to describe in e-mail, especially if they are "under the gun" and really need immediate help. ]
But in a professional environment, I _avoid_ e-mail because it is the ABSOLUTE WORST COMMUNICATION MEDIUM. There is no way to gage tone, intent, etc... If I have a consultant or employee that would rather communicate via e-mail for conversation than phone (or in person if he is local), that reflects _poorly_ on him.
To send logs, config files, etc..., yes, use e-mail for that. But for conversations, messages, etc... -- use the phone, give the person at the other side a sense more than what text can do. Limit your e-mail conversation to a notice or even a "hey, I send you a voice-mail" and do _not_ attempt conversation over it in a professional environment.
It says worlds about how much you _avoid_ meeting people, and it heavily factors into my opinion of a consultant or employee I'm paying! ;->
2: My embedded headless linux targets live in isolated networks, even relative to other computer or network equipment at the target site. At times, the nearest land is 2 miles straight down (ocean floor).
And your point is? You feel RBAC/MAC somehow requires a physical presence? Or you haven't addressed how RBAC/MAC should be setup before you send it out?
I don't put systems with RBAC/MAC in place _until_ it works as I've configured it. And that means I do _not_ change the functionality of the unit in the field, because it might not work because of such controls (or other things besides RBAC/MAC) if and when I do. I will replace the unit with a new, changed version that has been tested.
That's just good configuration management. It has _nothing_ to do with RBAC/MAC.
3: These targets are also without anything resembling a linux-aware operator and (ipso facto) must generate NO mail and self-limiting logs of a "usually ignored' type.
Well, that makes a little more sense. If you're not concerned with monitoring the unit for failure or compromise, then no, RBAC/MAC doesn't make sense. I'll give you that.
So how do you know the unit needs to be replaced? If it is your argument that you only need functionality, and that's the only time you would replace it (if it no longer did so), then that's agreeable. I.e., if someone compromises the system and piggy-backs functionality on the unit, that's not an issue, then I'll agree with you 100% -- RBAC/MAC offers you nothing.
from the above, SELinux offers me *nothing* I need and costs me something for which there is no reward.
-
Brian T. Brunner -
Bryan J. Smith -
Chris Mauritz -
Craig White -
Lamar Owen -
Les Mikesell -
Mark Belanger -
Sam Drinkard -
Tony Schreiner