Re: an actual hacked machine, in a preserved state

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On 1/2/2012 11:01 PM, John R. Dennison wrote:
> On Mon, Jan 02, 2012 at 10:41:15PM -0800, Bennett Haselton wrote:
>> Again, you don't have to take my word for it -- in the first 10 Google
>> hits of pages with people posting about the problem I ran into, none of
>> the people helping them, thought to suggest SELinux as the cause of the
>> problem.  (By contrast, when iptables causes a problem, people usually
>> figure out that's what's going on.)
> There's a lot of FUD going around in this thread.  If people would
> bother to spend some time _reading_ _documentation_ on the systems they
> are attempting to admin they might find that subsystems such as selinux
> aren't quite as complex as they make them out to be.

Well for one thing, much of the documentation for Linux tools is 
missing, unclear, or sometimes just wrong.  Here's a message I posted 
two years ago:
http://forums.mysql.com/read.php?11,280886,280886#msg-280886
about how when you first install MySQL, it tells you -- shouting in all 
caps, no less -- to set a password by running a pair of commands, where 
the second command is always guaranteed to fail (for reasons explained 
in the post).  I verified this on every dedicated server I had access 
to.  But the message never got answered, and for all I know MySQL still 
shouts the wrong information at every new user who installs it.

However, completely wrong documentation is actually rare; the problem 
with most documentation is that it's unclear or ambiguous, because it's 
written or judged with the mindset that users "should" know enough to 
resolve the ambiguities and the errors, and if the user doesn't know 
enough to figure out the errors, it's a failing on the user's part.  Or 
the documentation is extremely long-winded and doesn't contain a short 
version that is good enough for 99% of users' purposes, because it's 
assumed that if users don't want to read the 50-page version, that's 
also a failing on the user's part.

I think most unclear documentation could easily be made better.  I'd be 
happy to volunteer for a project where someone writing documentation 
wanted to check to see if it made sense to people who didn't already 
know what the author was trying to say.  But the authors have to want to 
do that.  The main obstacle is the mindset that problems with 
documentation are presumed to be the user's fault.

(To be fair, this isn't a problem specific to Linux documentation; many 
instructions out there are pretty bad, because it's notoriously 
difficult to judge the quality of instructions in a field in which 
you're an expert, since your brain automatically fixes errors and 
ambiguities if you know what the author was trying to say.  Recipes 
written by cooking experts are pretty bad.)

> Oh, and like all
> other aspects of the internet, google is just as susceptible to indexing
> idiots as it is to indexing pertinent and accurate results.
>
> selinux is fully integrated into the system auditing facilities and even
> provides multiple tools to aid an administrator in problem isolation
> and remediation.  These tools are, of course, fully documented.
>
> There is _ample_ documentation on the web, starting with the CentOS
> wiki site, that covers selinux in great detail.  I would urge you and
> anyone else not familiar with the facilities that selinux offers, both
> from an enforcement standpoint and also from a management standpoint, to
> spend some quality time reading up on it.
>
> Blaming selinux itself for creating what you perceive as a "problem"
> because you won't make a rudimentary attempt at learning to properly
> manage it is ludicrous.
>
> Anyone that has an internet facing box that does not take advantage of
> each and every security technology at their disposal should be in a
> different line of work.  And taking advantage of such technologies
> requires one to read associated documentation.
>
> And while this response seems to single you out I mean to point a
> finger at anyone out there that doesn't bother to take time to learn
> about systems / data that they are responsible for.
>
>
>
>
> 							John
>
>
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos


[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux