[CentOS] [OT][Practices] The Case for RBAC/MAC

[Bryan J. Smith]

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.