From: KaiGai Kohei <kaigai@ak.jp.nec.com>
To: "Christopher J. PeBenito" <cpebenito@tresys.com>
Cc: KaiGai Kohei <kaigai@kaigai.gr.jp>, selinux@tycho.nsa.gov
Subject: Re: [PATCH] SE-PostgreSQL Security Policy (try #3)
Date: Thu, 27 Mar 2008 18:52:01 +0900 [thread overview]
Message-ID: <47EB6E41.9040309@ak.jp.nec.com> (raw)
In-Reply-To: <1206451493.16113.217.camel@gorn.columbia.tresys.com>
Christopher J. PeBenito wrote:
> On Tue, 2008-03-25 at 19:35 +0900, KaiGai Kohei wrote:
>> 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.
>
> I think we want consistency across the policy in naming. Determining if
> it goes with a userspace object manager can be found based on what
> object classes have the label.
OK, I'll change the previous naming convention.
>>>>> 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.
>
> I think I was a little unclear. I'm suggesting they go in a file
> like /etc/selinux/refpolicy/contexts/postgresql_contexts, not in a
> primary config file for postgresql.
Yes, I have same implementation image as you suggested.
However, I don't want to add this kind of stuff although it can be described
within the security policy, because it provides us uncertainties on SE-PostgreSQL
behavior. It shall make harder to find out the cause of trouble came from labeling
matter as I said before.
I want to ask it again.
Do you consider they are really complex type_transition rules now?
They are not conditional, not set operations.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
next prev parent reply other threads:[~2008-03-27 15:11 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-13 9:29 [PATCH] SE-PostgreSQL Security Policy Kohei KaiGai
2008-02-25 16:30 ` Christopher J. PeBenito
2008-02-26 3:07 ` Kohei KaiGai
2008-02-27 8:00 ` Kohei KaiGai
2008-03-04 15:16 ` KaiGai Kohei
2008-03-06 15:27 ` Christopher J. PeBenito
2008-03-06 18:51 ` Joshua Brindle
2008-03-07 2:20 ` Kohei KaiGai
2008-03-07 16:16 ` Joshua Brindle
2008-03-08 1:33 ` KaiGai Kohei
2008-03-07 1:52 ` Kohei KaiGai
2008-03-07 9:32 ` Kohei KaiGai
2008-03-07 20:48 ` Christopher J. PeBenito
2008-03-09 14:24 ` KaiGai Kohei
2008-03-11 12:57 ` Christopher J. PeBenito
2008-03-11 16:57 ` KaiGai Kohei
2008-03-12 8:42 ` Kohei KaiGai
2008-03-17 9:31 ` [PATCH] SE-PostgreSQL Security Policy (try #3) Kohei KaiGai
2008-03-19 14:45 ` Christopher J. PeBenito
2008-03-21 4:32 ` KaiGai Kohei
2008-03-21 5:11 ` KaiGai Kohei
2008-03-24 18:44 ` Christopher J. PeBenito
2008-03-25 10:35 ` KaiGai Kohei
2008-03-25 13:24 ` Christopher J. PeBenito
2008-03-27 9:52 ` KaiGai Kohei [this message]
2008-03-27 13:23 ` Christopher J. PeBenito
2008-03-28 4:50 ` KaiGai Kohei
2008-05-05 13:48 ` Christopher J. PeBenito
2008-05-12 2:31 ` KaiGai Kohei
2008-05-12 14:33 ` KaiGai Kohei
[not found] ` <1210615044.11188.17.camel@gorn>
2008-05-13 2:39 ` KaiGai Kohei
2008-03-10 7:52 ` [PATCH] SE-PostgreSQL Security Policy Kohei KaiGai
2008-03-11 12:30 ` Christopher J. PeBenito
2008-03-11 13:03 ` KaiGai Kohei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47EB6E41.9040309@ak.jp.nec.com \
--to=kaigai@ak.jp.nec.com \
--cc=cpebenito@tresys.com \
--cc=kaigai@kaigai.gr.jp \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.