SELinux last straw

Andy Green andy at warmcat.com
Wed Oct 17 18:36:19 UTC 2007


Somebody in the thread at some point said:

>>> With traditional unix security a few
>>> simple checks can determine the status and any similar problem reported
>>> to this list would have an immediate response with the fix or a test to
>>> identify the problem.  With this, we not only do not have an answer, in
>>> the months this thread has continued, not only is there not a fix, no
>>> one has produced a diagnostic test to even identify the issue.
>>
>> I don't agree, the OP simply doesn't follow instructions and so in
>> capable of assisting with remote diagnosis.
> 
> But there haven't been any instructions other than handwaving about
> reading and interpreting obscure logs.  What specific test was suggested
> that he failed to run?

I recently once more tried Gnome as my desktop as I periodically do, it
is much better than last time.  One of the things it runs automatically,
which KDE didn't AFAICT, is a tray app called setroubleshooter.  If an
AVC is seen, it pops up a GUI discussing it and the actions you might
want to take, listing AVCs it has seen with counts and dates.

On "instructions", FOSS support trying to fix some random problem from
some random person over the Internet whose machine you will never see is
a cooperative venture.  If the other half of it just wants to moan about
it or 'prove' something then nothing is going to get fixed.

Sometimes you come across a guy with a problem and he is as keen as
mustard to fix it, truly grip the cause and flow of it soup to nuts,
will do difficult tests and report clearly, it's a real pleasure working
with them (and not least fully sharing that understanding and education
if you succeed).

And sometimes there is no goal or point because the guy already figures
he "knows" what the "problem" is, but there is no story about how or why
and he doesn't even want one, in case it conflicts with the Only True
Version from "the bible".

>>> How are you supposed to determine the 'correctness' of a given setup?
>>
>> I don't understand what you mean by this.
> 
> If I asked how to determine whether or not some particular access would
> be permitted or denied by the traditional unix mechanism you wouldn't
> have any trouble describing how to verify it in terms of permissions
> down the file path.  I'm asking the same question about SELinux.
> 
> How, for example, would you determine if some change will make it
> necessary to relabel?   How, other than running something and letting it
> fail to get the log message, do you positively determine that some
> specific access will be permitted or denied?

If you can't see the pam config or resolv.conf on an unknown box you
don't know what will work either until you start trying and look.
Permissive was useful for me to gingerly add selinux to a remote box
that never had it before, the box couldn't be killed but I could learn
where the issues were (a handful, FWIW).  I turned it straight to
enforcing and rebooted and fixed them up.

The one golden rule I found seems to be to do with avoiding mv and using
cp when introducing files to a new selinux directory tree.  So if you
created files in ~ and mv them to /var/www/html, because it is done by
shifting inodes around and not creating files, they will retain the home
directory related selinux label and make trouble.  If you cp'd them
over, new files are created in the new directory context, they will have
httpd-related labels.

-Andy




More information about the fedora-list mailing list