Christopher J. PeBenito wrote:
> On Mon, 2008-06-02 at 13:31 -0400, Eamon Walsh wrote:
>> KaiGai Kohei wrote:
>>> Christopher J. PeBenito wrote:
>>>> On Thu, 2008-05-29 at 20:22 -0400, Eamon Walsh wrote:
>>>>> Christopher J. PeBenito wrote:
>>>>>> On Thu, 2008-05-29 at 14:05 -0400, Eamon Walsh wrote:
>>>>>>> Christopher J. PeBenito wrote:
>>>>>>>> On Tue, 2008-05-27 at 16:15 -0400, Eamon Walsh wrote:
>>>>>>>>> Christopher J. PeBenito wrote:
>>>>>>>>>> On Tue, 2008-05-27 at 14:34 -0400, Stephen Smalley wrote:
>>>>>>>>>>> On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote:
>>>>>>>>>>>> I mainly had an issue with statements like:
>>>>>>>>>>>>
>>>>>>>>>>>> type_transition postgresql_t postgresql_t:db_database sepgsql_db_t;
>>>>>>>>>>>> type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t;
>>>>>>>>>>>> type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t;
>>>>>>>>>>>> type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t;
>>>>>>>>>>>> type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t;
>>>>>>>>>>>>
>>>>>>>>> I don't see the problem with the above statements - seems like a
>>>>>>>>> reasonable use of transitions to me. If you don't like the first four
>>>>>>>>> transitions, then I would ask -- why not simply eliminate the target
>>>>>>>>> types in those rules and label all of those objects with postgresql_t
>>>>>>>>> (default transition)? Clearly the names are just for convenience. You
>>>>>>>>> did a similar thing with the X policy: going through and combining types.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I don't think this is the same situation. Having a table labeled
>>>>>>>> postgresql_t doesn't make sense to me, since postgresql_t is the type of
>>>>>>>> the server process. Though, I suppose that if it wasn't an object
>>>>>>>> manager, then the objects would implicitly be postgresql_t and/or
>>>>>>>> postgresql_db_t. So to conclude my stream of consciousness, I'm
>>>>>>>> compelled by your argument, but I'm not sure its enough to change my
>>>>>>>> position
>>>>>>>>
>>>>>>>>
>>>>>>> If it's not the same situation, it sounds pretty darn close: the X
>>>>>>> server also acts as a "client" when it starts up, and various objects
>>>>>>> are created by the server before any real clients connect. For example
>>>>>>> root window and default colormap.
>>>>>>>
>>>>>>> From xserver.if:
>>>>>>>
>>>>>>> # Labeling rules for default windows and colormaps
>>>>>>> type_transition $1_xserver_t $1_xserver_t:{ x_drawable x_colormap } $1_rootwindow_t;
>>>>>>>
>>>>>>>
>>>>>> Its significantly different since this deals with derived types while
>>>>>> postgres doesn't.
>>>>>>
>>>>>>
>>>>> That's the policy writer's decision to make. What if I make my own
>>>>> policy and I want to use derived types for postgres?
>>>>>
>>>> I never argued that type transitions shouldn't work. My problem is the
>>>> default type in the absence of type transitions. In fact there are
>>>> derived types in the current postgres policy, and I'm fine with them.
>>>>
>> It sounds to me like selabel might be best for this. The tables,
>> databases, procedures, and blobs have names, and those names can be used
>> in a mapping to contexts. There can be setcreatecon overrides to this as
>> well. selabel has a wildcard for setting a default context.
>>
>> But putting a hard-coded context into a file just to avoid a few type
>> transition rules is totally bogus to me. I find it strange that it's
>> considered a "simplification" to use a default_context file rather than
>> policy rules, as though it's some kind of huge win. Adding a
>> default_context file requires new libselinux API, which bloat affects
>> all SELinux users. I've also never seen a coherent solution for managing
>> these files. They are part of the security policy, which means updates
>> to them must be atomic with the policy load or there will be race
>> conditions affecting their users.
>
> I'm out of arguments; clearly I'm in the minority on this issue. I
> already said I wouldn't block the policy over this, so KaiGai, if you
> would send a last patch based on the revisions I made [1], let see if we
> can finally get this merged.
>
> [1] http://marc.info/?l=selinux&m=120999566809541&w=2
I'll submit a revised version later.
(Now we cannot update SVN repository, due to server maintenance.)
Before this, I want to modify the following points:
- neverallow rule should be removed, as you suggested before.
- The type_transition rule for newly created database should be
described with "self" as its target, like:
type_transition sepgsql_client_type self : db_database sepgsql_db_t;
The purpose is to make clear its meanings that this type_transition
has no appropriate parent as socket creation.
- postgresql_unconfined() interface should also associate a domin
with sepgsql_client_type, not only sepgsql_unconfined_type.
dontaudit rules on row-level logs are not disabled for unconfined
clients. And, it's not useful to write additional policy module.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@xxxxxxxxxxxxx>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
