KaiGai Kohei <kai...@ak.jp.nec.com> writes: > Joshua D. Drake wrote: >> I just did a little research and it appears the other two big names in >> this world (Novel and Ubuntu) are using something called App Armor.
> As far as I can see, SUSE, Ubuntu and Debian provide SELinux option. > But they are more conservative than RedHat/Fedora, because it is not > enabled in the default installation. > I don't think it is unpreferable decision. Users can choose the option > by themself according to requirements in the system. Based on Red Hat's experience, it is a safe bet that not enabling SELinux by default guarantees the feature will remain useless to the average user. As was pointed out upthread (and I can confirm from personal experience), it's taken *years* for Red Hat to develop the security policy to a point where it's even marginally usable by anyone who isn't willing to put up with a great deal of annoyance because they have an extreme need. And that's despite having a well-defined, not too ambitious goal for what it is they are trying to secure: for the most part, RH's default policy doesn't try to lock down anything except network-accessible services. SUSE and the rest of them may "have the feature", but they don't have it in a usable form, and won't ever have it without a much larger effort than they're making. Even if we were to accept the SEPostgres patches lock stock and barrel tomorrow, I don't foresee that it will ever get to the point of being useful except to an extremely small group of users who are driven by extreme need. Nobody else is going to have the motivation needed to develop custom security policies, and there simply isn't any chance of anyone developing any generally useful default policy. Red Hat's policy has been trying to cope with cases like "which directories should Apache be allowed to read, *given that it's running a Red-Hat-standard configuration*?" That's far more circumscribed than any useful database policy would be, because database applications aren't nearly that standardized. If SEPostgres were a small patch that wouldn't need much ongoing effort, I might think it's reasonable to adopt it for the benefit of only a small group of users. However, it's not small, it's not simple, and it will not be low-maintenance. I'm afraid the cost-benefit ratio from the project's perspective is just not reasonable. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers