Aidan Van Dyk wrote:
> * Robert Haas <robertmhaas@gmail.com> [080924 00:15]:
>
>> But I do think
>> it's worthwhile to ask whether it makes sense to introduce a bunch of
>> features that are only usable to people running SELinux.
>
> Actually, I'ld go one stroke farther, and ask:
> Does it make sense to introduce a bunch of features that are only
> usable to people *able to write proper SELinux policy sets* (or whatever
> they are called).
It is incorrect.
In the recent years, SELinux comunity aspires to becoming that end users
can setup it without editing security policy. The default security policy
contains many pre-defined object types and booleans, end user can select
them, if needed.
For example, the default security policy of SE-PostgreSQL provides several
pre-defined object types, like sepgsql_table_t, sepgsql_secret_table_t,
sepgsql_ro_table_t and sepgsql_fixed_table_t for table/column/tuple.
>> it's very easy to imagine
>> people wanting that feature, but NOT being willing to run SELinux to
>> get it.
>
> Or, being more generous even, able to *run* SELinux, but not able to
> create a proper coherent set of SELinux policies... SELinux is
> "standard" now on most RHEL installs (and FC, and now debian, etc), but
> how many admins have actually "made" (or even just altered) a SELinux
> policy, and how many have just disabled it because it prevented what
> they thought should be a valid operation?
Can you think the security policy is something like a pattern file of
anti-virus software running on windows desktop? I allows end-users to
custamize some of options, but I have never seen a man who tries to
make its pattern file by myself.
Anyway, I don't think we can get a fruitful discussion like "how many
users enables SELinux" here. Here is pgsql-hackers list.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
