Re: [PATCH] SE-PostgreSQL Security Policy (try #3)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Christopher J. PeBenito wrote:
> On Fri, 2008-03-21 at 13:32 +0900, KaiGai Kohei wrote:
>> Chris, Thanks for your reviewing.
>>
>> Rest of comments are bellow.
>>
>> Christopher J. PeBenito wrote:
>>> On Mon, 2008-03-17 at 18:31 +0900, Kohei KaiGai wrote:
>>>> The attached patch provides revised SE-PostgreSQL policy.
> 
>>>> +template(`postgresql_userdom_template',`
>>   - snip -
>>>> +       ##############################
>>>> +       #
>>>> +       # Client local policy
>>>> +       #
>>>> +       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_database_type : db_table     sepgsql_$1_table_t;
>>>> +       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_database_type : db_procedure sepgsql_$1_proc_t;
>>>> +       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_database_type : db_blob      sepgsql_$1_blob_t;
>>>> +       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_sysobj_t      : db_tuple     sepgsql_$1_sysobj_t;
> 
> I missed this previously but I just realized that to be consistent with
> the rest of the policy the prefix should actually be a prefix, not
> infix.  i.e. the types should be like $1_sepgsql_table_t not sepgsql_
> $1_table_t.

I want to keep "sepgsql_" as a prefix for types related to SE-PostgreSQL,
because all of them have uniformed naming convention.
Can you consider the head of "sepgsql_" means its assumed object manager,
and we are omitting it for most of types managed by kernel?
I feel that object manager identification should have higher priority than
user domain prefix in naming convention.
In my sense, "kernel_user_home_t" is better than "user_kernel_home_t",
if object manager identification is not omitted.

However, it is just a name. I don't oppose this strongly.

>>> This should probably transition even if its unconfined.  If a user
>>> starts out unconfined and then the admin later decides the user should
>>> be confined, the user will lose access to its object, right?
>> No. In this case, a new confined user can access to its object if it was
>> not explicitly relabeled.
>> The default type of db_table class created by unconfined users is sepgsql_table_t.
>> Any confined users can also access to them with restricted permissions.
> 
> I finally realized what the problem with the type_transitions.  You have
> many of them to set up the default type for tables, procedures, blobs,
> etc.  Shouldn't the default labels just be settings in a config file?
> Then all of the complex type transitioning behavior isn't needed.

I dislike thie option.
It can make harder to find out the cause of trouble came from labeling behavior,
if end users put incorrect configuration. Especially, I don't want to require
database folks additional configuration, because they are not SELinux specialist.
It can be configured in the security policy enough simply, so the default behavior
should be also described in.

In the latest patch, these rules are simpler.
  Domains with template    -> sepgsql_FOO_table_t convention
  Domains without template -> sepgsql_table_t convention
We have no conditional type_transition, negative operations now.

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.

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux