All of lore.kernel.org
 help / color / mirror / Atom feed
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: Tue, 25 Mar 2008 19:35:55 +0900	[thread overview]
Message-ID: <47E8D58B.5040707@ak.jp.nec.com> (raw)
In-Reply-To: <1206384282.16113.205.camel@gorn.columbia.tresys.com>

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@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.

  reply	other threads:[~2008-03-25 10:36 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 [this message]
2008-03-25 13:24                           ` Christopher J. PeBenito
2008-03-27  9:52                             ` KaiGai Kohei
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=47E8D58B.5040707@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.