[CentOS] SELinux and access across 'similar types'
bennett at peacefire.org
Wed Jan 11 10:19:18 UTC 2012
On 1/10/2012 12:52 PM, 夜神 岩男 wrote:
> On 01/11/2012 05:04 AM, Les Mikesell wrote:
>> On Tue, Jan 10, 2012 at 1:46 PM, Daniel J Walsh<dwalsh at redhat.com> wrote:
>>>>> On Tue, Jan 10, 2012 at 7:47 AM, Daniel J Walsh
>>>>>> <dwalsh at redhat.com> wrote:
>>>>>>> Now if only more people used RHEL we could further enhance
>>>>>>> the products. :^)
>>>>>> Why isn't it accepted as more of a standard?
>>>>> I don't understand the question.
>>>> Why is it vendor-specific to RHEL?
>>> I was talking Money not vendor specific. The question meant as a jab
>>> was if more people used RHEL instead of Centos, we could pay more
>>> developers. I thought the @redhat.com would signify why I would want
>>> that. :^)
>> OK, I can understand why you would want that. I don't understand why
>> you think anyone else would want even more nonstandard variations in
>> linux distributions. And if this isn't intended to be
>> vendor-specific, why isn't it an independent upstream project or
>> included in the kernel?
> The logical code to SELinux isn't specific to RH, not by a long shot.
> (Of course, RH may wind up doing some way un-Unixy/very-vendor-specific
> things in the near future, but that has nothing to do with SELinux)
> But the difficult thing about SELinux isn't how it works, its the detail
> required for each policy to wrap each program up correctly without
> denying useful functionality in the process, not to mention deploying
> them with packages, and dealing with the whole new universe of
> inaccurate bug reports SELinux has spawned...
> *That* is very hard -- and that is what Red Hat has been so good about
> over the last while. In the process Fedora has spawned a slew of new
> tools to make SELinux policy easier to deal with -- and in the process
> of doing that Fedora acquired/affirmed its reputation for eating babies.
> SElinux exists all over the place, and there are binaries for it in
> nearly every distro -- but nearly everyone has decided that "its too
> hard" so its just a set of accessory packages almost nobody installs,
> and if installed not activated, and if activated quickly de-activated
> (the #1 web server "fix your frustrations on the web" advice for noobs
> is still "disable SELinux, it sux").
> Honestly, though, at this point the tools really are there. A packager
> that wants to publish an SELinux policy with his package finds it easy
> if the tools are understood -- what is really lacking now is just a very
> public, beginner-friendly introduction to the core concepts of SELinux
> which includes a nice intro to the somewhat arbitrary jargon that
> surrounds access policy concepts.
Well there is already a beginner-friendly introduction:
The problem I had with it is that there are several statements that are
unclear, missing, or just wrong. That's not necessarily the fault of the
author; if I had to write an intro to something that I knew a lot about,
I'd probably also make a few statements that were unclear or wrong.
The cure for that is to show it to 10 people whose intelligence you are
reasonably confident about, but who *don't already know* what the
document is trying to teach, and ask them to suggest edits: anything
that tells the user to "do something" without saying how, or is unclear,
or doesn't work when they try it. Then when the documentation has been
tweaked enough that it no longer has too many of those problem areas,
then it's "ready".
(If I were a volunteer, some of my suggested edits to that page would be:
- Near the beginning the doc says "the machine should be rebooted and
the filesystem relabeled", without telling the user how to actually do
that. Have a forward-reference telling the user where to read how to
relabel the filesystem.
- The sentence about "Access is only allowed between similar types" is
apparently wrong (and meaningless anyway if it doesn't explain what
"similar types" means). I would just go ahead and say that there's no
way to know for sure what process types will be allowed to access what
file types, and all you can do is make educated guesses based on the
similarity of the names, and then look at error logs afterwards to see
if you were right.
- Explain that files in /tmp/ aren't relabeled after rebooting. (If
indeed that is the case. We never did figure out why my /tmp/ files
weren't being relabeled.)
- The "genhomedircon" command gives an error if SELinux is enforcing;
switch to permissive before running that command.
- The doc says httpd runs in the httpd_t security context. This is only
true if it's started silently; if the user starts it from the command
line, it runs in a different context.)
It doesn't take that much work to turn so-so documentation into really
useful documentation, but you have to start with the assumption that
there is room for improvement. The main obstacle is the attitude of
people like John Dennison, who assume the documentation is fine the way
it is, and that any problems are therefore the fault of the user: "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...
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." (Even though it subsequently came out that I
was in fact following the instructions on the wiki, and there were steps
missing in the instructions.)
Why not try producing documentation that passes the 10-smart-newbies
test, and then point people to that, whenever they run into problems
caused by SELinux?
But if it takes an average of four days to fix a typical problem caused
by SELinux, *even following the documentation* (and even, for that
matter, having a whole list to help you!), then of course people aren't
going to use it.
> Minds are very slowly changing and I am beginning to see a lot more
> functionality in non-Fedora-derived distros, but it takes a long time to
> turn the tide several years' worth of mailing archive, newsgroup, blog
> and forum advice *against* learning SELinux and turning it off instead
> -- and of course the biggest problem with that advice for those new to
> SELinux is that often it produces instant gratification.
> CentOS mailing list
> CentOS at centos.org
More information about the CentOS