[colug-432] SELinux == Sadness

[R P Herrold]

On Sun, 25 Apr 2010, Jeff Frontz wrote:

> outside world; I'm designing an embedded product.  If I can mitigate
> the risk of external manipulation using other tools/mechanisms (e.g.,
> no more login/getty), then that's a way simpler path than trying to
> come up-to-speed by reading a bunch of web sites and mailing lists.
> Don't get me wrong--I'm not trying to stand in the path of progress; I
> just have only so much time in the day to learn the latest Best Thing
> Ever.

Data security is about process and about risk identification, 
and not obtaining an absolute state.  Off the top of my head, 
I know at least three exploit vectors remaining after a person 
would follow the outline at:
 	http://www.pmman.com/usage/hardening/
but the exploits are sufficiently hard to invoke, that I'm 
confortable that all we have seen tries to exploit are 
addressed, and that warnings from some early notification 
systems would permit us to see and stop the remaining ones 
before they might be effective

> And again, I'll profess ignorance and throw myself at your mercy-- how
> about giving a preso about this topic in the next few weeks?  I'll
> even help secure a spot: on Monday, I'll walk over to the person who
> schedules meeting space at TechColumbus and ask her what's available.
>
> Deal?

not really, as COLUG stopped being fun to present at, and so 
stopped meeting because people were not interested in esoteric 
topics I (and Jim Wildman, and Travis, etc) felt were worthy 
of presenting on.  In all honesty, Linux is mainstream and 
well enough documented these days, and I have to decide 
what to do first, and what to pass on.

If it is not worth it to you to habituate yourself to 
sysadminning in a fashion that I think is basic, I'm not going 
to argue about it or try to give you something you likely 
won't use.

This is the FOSS value proposition all over again.  One can 
buy a turnkey solution complete with a SLA throat to choke 
with dollars and get what the packager designed by way of 
featureset, or one can spend the time and effort to build 
solutions that meet the particular and exact requirements one 
feels needful.

For example, in doing bioinformatics or financial engineering, 
Matlab may meet some needs; but Matlab is a proprietary closed 
source approach, compared to 'R'.  I was sharpening my skills 
at the R/Finance 2010 conference last weekend in Chicago, as 
it is a extensible tool meets _my_ needs, and it met my needs 
a decade ago when I was approached by Yellow Dog to do some 
custom RPM packaging of Boost, and other parts of the 
toolchain R needs as a contractor

Neither approach is right nor wrong, and if a (believed) 
protected environment works for your direct report chain, I'm 
not going to argue it.  As a competitor, I'll just wait for 
that firm to 'blow up' in a 'black swan' event, and still be 
there in the market

-- Russ herrold