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.