CentOS - Nov 2005 - [OT][Practices] The Case for RBAC/MAC

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 at gai-tronics.com
(610)796-5838
>>> thebs413 at earthlink.net 11/17/05 06:38PM >>>
Chris Mauritz <chrism at 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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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 Brunner
brian.t.brunner at gai-tronics.com
(610)796-5838
>>> thebs413 at earthlink.net 11/18/05 09:40AM >>>
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.
This concurs with my asserted point: e-mail is a personal skill.
>> 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?  
Slightly beyond your grasp?  Who, pray tell, is my attacker?
>> 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.  
YAYYY!  I've passed a cognitive coherence test from somebody
whose methods of presentation in e-mail are sufficiently poor 
that I SIMPLY DON'T CARE whether I pass his tests.

Once again, I depart from this conversation.

*******************************************************************
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