[CentOS] SELinux and access across 'similar types'

夜神 岩男 supergiantpotato at yahoo.co.jp
Wed Jan 11 13:09:22 UTC 2012


On 01/11/2012 11:07 AM, Les Mikesell wrote:
> On Tue, Jan 10, 2012 at 3:50 PM, Daniel J Walsh<dwalsh at redhat.com>  wrote:
>>>>
>> That is not the way it works.  SELinux Reference policy is a database
>> of rules that govern the default ways application run.
>
> Yes, but it is application developers that know what their
> applications need to do.  Is there a way for them to express that?

This gets back to the core problem of people often just not learning 
SELinux in the first place. Its not RH or Fedora's problem if upstream 
developers trying to port Windows apps to Fedora dont, for example, 
understand Unix permissions. Various distros deal with such problems in 
various ways. This family's response was to write troubleshooting tools, 
start writing docs and get packagers on-board with it -- other distros' 
responses varied but tended toward "scary, this thing... let's just 
quietly include binaries but not turn the scary spinning thing on... 
heaven forbid we learn anything new"

>>    These rules
>> that have been written for Fedora/RHEL are public and are being moved
>> upstream.
>
> There has to be a better approach than letting the Fedora guys
> second-guess where application components should live, then
> second-guess what the application needs to do.   In fact, that sounds
> like a recipe for years of problems for everyone who uses the results.

Honestly, SELinux is far less of a complication -- be it within a distro 
or across the Unixcape (new word?) -- than the current proliferation of 
different init subsystems. There is, for example, no tool that can even 
give you reasonable hints to get your daemons from SysV to Upstart to 
Systemd. Trying just to package for Upstart between distros can be a 
nightmare. SELinux is, by comparison, far easier to develop a basic, 
reasonably sane (if not as tight as could be) policy to distribute per 
package.

>>   Different Distributions can choose to use these policies or
>> write there own.
>
> So after the Fedora version of second-guessing, that gets pushed off
> to other distributions to likely make it even worse?

I'm assuming this is a joke. Fedora already ate (almost) all the babies. 
Seriously. I lived through it and now I find SELinux a breeze, and 
audit2allow is *really* quite a livable tool to work with. You're 
talking like other distro's burden somehow belongs to Fedora. Fedora's 
burdens aren't even RH's problem -- RH only picks what it finds as 
useful for its customer base out of Fedora, and SELinux is very high on 
the list of "incredibly useful things". But just like PostgreSQL, 
Sendmail, Apache2, Bash, Awk, Sed (the list is long) all the really 
powerful stuff, new or old, requires some study.

You're expecting to get a system-wide mandatory access control policy 
system across every distro based solely on Fedora's efforts (as if 
Fedora is actively pushing SELinux to other distros) without the 
users/sysadmins needing to do some reading? When was the last time you 
ever heard of a safe, secure, all-encompassing web (or otherwise) CMS, 
for example, that didn't require at least some configuration and knowhow?

>>   Out of the Reference Policy you can build your own
>> version of targeted or MLS policy or you can write your policy from
>> scratch.
>
> But is there a way that these can originate from the group that
> manages the application, and appear automatically as a result in
> distributions that include the application or if you compile from the
> source distribution?

Upstream projects can certainly assist enormously by learning about 
SELinux and writing guidelines ahead of time, and some of the larger 
projects have such people (Postgres is a good example of this), but just 
like startup scripts, installation, linking, $PATH-related and 
compile-time library linking decisions SELinux policy is *heavily* the 
responsibility of the packager/distro maintainer, *not* the upstream 
itself. Each distro has its own quirks and nearly every package on every 
system has to work around these as constraints.

SELinux policy is not the hardest thing a packager has to deal with, 
IMO. Its one of those things that if a project has sane guidelines to 
cover (which many, perhaps most, distros lack on for many things) is not 
too hard to deal with, but must be learned through experience at play 
and study, just like RPM.

>> The place that SELinux breaks applications is when an application does
>> something that SELinux did not expect.
>
> Well, of course.   The issue is how SELinux is supposed to learn from
> the person who does know what the application is going to do.  I don't
> run an OS distribution to what a distribution does, I run it so it
> does what the application is supposed to do.  That is, the application
> is the point, not what SELinux guesses it was supposed to do.

That's what the auditing tools can help you out with. Outside of that, 
you're asking for Microsoft-style defaults, which is ridiculous.

There is no way, for example, that you could consider it a sane default 
to permit Apache, on a basic installation, to automatically index 
directories and serve files from NFS mounted /home partitions and call 
that secure -- and definitely not to do so while invoking background 
code that resides in those directories, sending mail out or exercising 
any sort of database access (which I guess would have to also all be 
enabled in your favored default policy?).

This is precisely what a lot of people use Apache on rpm-based distros 
to do with their systems, of course, but it can never be anything other 
than a measured decision and one that requires a lot of deliberate 
operator involvement. Altering the running SELinux policy sits 
comfortably among the other admin tasks necessary to get such a system 
working properly.

>> I wrote a paper and
>> presentation on the four main causes of SELinux issues.
>>
>> http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/selinux_four_things.pdf
>
> Don't these all boil done to SELinux not understanding the application's needs?

That's like saying that httpd.conf and Postgres don't understand my 
wiki's needs because I have to touch them before anything can be shown 
to the world.

You don't have to touch SELinux policy to just fire up a browser and 
check out wasteoftime.com, enhance your image GIMP or click your life 
away inside SooperOffice9000.org. That doesn't threaten to compromise 
your system. But if you want to permit your office program to execute 
arbitrary scripts received from wasteoftime.com automatically then that 
would require some configuration because its potentially dangerous.

How is that not a reasonable situation?

Anyway, if you don't like SELinux, just don't use it. Its a great 
security tool, but its always possible to just turn it off. If that 
doesn't float your boat, then you have to learn about it. That's how it 
is with all powertools. Complaining or insisting that Fedora or RH 
somehow magically fix packaging policy for every other distribution, 
however, are not realistic options, nor is "Yeah, I *want* it to enforce 
stuff, but I don't want to know what those things are, how they work or 
to ever have to explain those things to the system when its at a loss 
amongst the millions of interactions which occur in my system every 
second or the billions of potential states which can arise. I also 
refuse to read the man pages for chmod and chown. The system should just 
know who owns what and why, the way Windows used to -- now *that* was 
slick!"



More information about the CentOS mailing list