[CentOS] SELinux and access across 'similar types'

[Les Mikesell]

2012/1/11 夜神　岩男 <supergiantpotato at yahoo.co.jp>:
>
>>> 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.

No, that's not the issue.  The issue is that RH and Fedora have
consistently shipped kernels and glibc's (etc., etc.) full of flaws
that are trivially exploited to let anyone become root, and then they
try to slap bandaids on the applications in a so-so attempt to keep
things from being able to get to those vulnerabilities.

>> 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.

No, its not a joke.  Doctors get to bury their mistakes, but this is
more of an architectural issue where the best you can do is plant
vines to cover up a bad design.  The vines may have grown over old
applications, but if I were to write a new one today, how would I
include a configuration that would work regardless of the
distribution?

> 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.

Leave Fedora out of the picture.  The burden (or capabiliy, depending
on how you look at it) should belong to the application designer.
SELinux needs a way for the application designer to tell it what to
permit the application to do.   Anything else is equivalent to every
distribution needing to go rewrite the mode parameters on every open()
in every application before the app will work.

>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.

Study?  Do you mean that people who don't understand them are making
these changes?  And you expect them to get it right?

> 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?

You have it backwards.  I'm saying it needs the knowhow of the
upstream application developer, not someone guessing at what they
meant to do.

> SELinux policy is not the hardest thing a packager has to deal with,
> IMO.

Can you quantify that - like with the number of Fedora bugs it produced?

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

Beg your pardon?

> 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?).

I don't understand your point here.  Are you saying that SELinux is
not well matched to typical tasks on Linux systems?

> Complaining or insisting that Fedora or RH
> somehow magically fix packaging policy for every other distribution,
> however, are not realistic options,

Having distribution packagers make these changes doesn't make any more
sense than having them write the application source code in the first
place.

> 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 consider the application writer to be the expert here, and would
like just as little intervention by the packagers and sysadmins as we
can get away with while the distributions keep shipping kernel and
glibc vulnerabilities.

> 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!"

You are out of line there.  chmod and chown are well documented and
follow standards.  And if an application runs them, they work in spite
of most distributions efforts to break standards and emulate
proprietary systems to lock you in.  And if I run them, I expect them
to work exactly the same on anything that claims to resemble unix or
Posix.

-- 
   Les Mikesell
    lesmikesell at gmail.com