Ron Mayer wrote:
> Joshua D. Drake wrote:
>> On Tue, 2009-12-01 at 14:46 -0500, Tom Lane wrote:
>>> "Joshua D. Drake" writes:
On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote:
> This is totally separate from the really important question of whether
> SE-Linux has a future, and an
Greg Stark wrote:
> So I'm unclear what advantage this has for Redhat and sysadmins over
> just setting up the database directly but then I'm unclear what the
> advantage is for SELinux in the first place so I'm probably just not
> in the target audience for it. But this seems like it would be
> di
Joshua D. Drake wrote:
> On Tue, 2009-12-01 at 14:46 -0500, Tom Lane wrote:
>> "Joshua D. Drake" writes:
>>> On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote:
This is totally separate from the really important question of whether
SE-Linux has a future, and another about whether, if
On Wed, Dec 2, 2009 at 3:30 AM, Tom Lane wrote:
> Red Hat's
> policy has been trying to cope with cases like "which directories should
> Apache be allowed to read, *given that it's running a Red-Hat-standard
> configuration*?" That's far more circumscribed than any useful database
> policy would
Tom Lane wrote:
> Even if we were to accept the SEPostgres patches lock stock and barrel
> tomorrow, I don't foresee that it will ever get to the point of being
> useful except to an extremely small group of users who are driven by
> extreme need. Nobody else is going to have the motivation needed
KaiGai Kohei writes:
> Joshua D. Drake wrote:
>> I just did a little research and it appears the other two big names in
>> this world (Novel and Ubuntu) are using something called App Armor.
> As far as I can see, SUSE, Ubuntu and Debian provide SELinux option.
> But they are more conservative th
Greg Williamson wrote:
> As far as I can see, SUSE, Ubuntu and Debian provide SELinux
> option. But they are more conservative than RedHat/Fedora,
> because it is not enabled in the default installation.
>
> I don't think it is unpreferable decision. Users can choose the
> option by themself acco
KaiGai Kohei wrote:
===
Joshua D. Drake wrote:
> On Tue, 2009-12-01 at 14:46 -0500, Tom Lane wrote:
>> "Joshua D. Drake" writes:
>>> On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote:
This is totally separate from the really important question of whether
SE-Linux has a future, and
Joshua D. Drake wrote:
> On Tue, 2009-12-01 at 14:46 -0500, Tom Lane wrote:
>> "Joshua D. Drake" writes:
>>> On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote:
This is totally separate from the really important question of whether
SE-Linux has a future, and another about whether, if
Tom Lane wrote:
> "Joshua D. Drake" writes:
>> On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote:
>>> This is totally separate from the really important question of whether
>>> SE-Linux has a future, and another about whether, if SE-Linux has a
>>> future, PostgreSQL needs to go there.
>
>> W
Josh Berkus wrote:
>> This is totally separate from the really important question of whether
>> SE-Linux has a future, and another about whether, if SE-Linux has a
>> future, PostgreSQL needs to go there.
>
> If the hooks are generic enough that the could potentially be adapted to
> other security
On Tue, 2009-12-01 at 14:46 -0500, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote:
> >> This is totally separate from the really important question of whether
> >> SE-Linux has a future, and another about whether, if SE-Linux has a
> >> future
"Joshua D. Drake" writes:
> On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote:
>> This is totally separate from the really important question of whether
>> SE-Linux has a future, and another about whether, if SE-Linux has a
>> future, PostgreSQL needs to go there.
> Why would we think that it
On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote:
> This is totally separate from the really important question of whether
> SE-Linux has a future, and another about whether, if SE-Linux has a
> future, PostgreSQL needs to go there.
Why would we think that it doesn't? Maybe I haven't been fo
> This is totally separate from the really important question of whether
> SE-Linux has a future, and another about whether, if SE-Linux has a
> future, PostgreSQL needs to go there.
If the hooks are generic enough that the could potentially be adapted to
other security frameworks, yes. The need
David Fetter wrote:
> On Mon, Nov 30, 2009 at 11:03:08PM -0500, Bruce Momjian wrote:
>> KaiGai Kohei wrote:
>>> In summary, it was similar approach with what I already proposed
>>> in the CF#2, but rejected.
>>>
>>> During the first commit-fest of v8.5 development cycle, Stephen
>>> Frost suggested
Bruce Momjian wrote:
> KaiGai Kohei wrote:
>> In summary, it was similar approach with what I already proposed in the CF#2,
>> but rejected.
>>
>> During the first commit-fest of v8.5 development cycle, Stephen Frost
>> suggested
>> to rework the default PG's access controls to host other optional
On Mon, Nov 30, 2009 at 11:03:08PM -0500, Bruce Momjian wrote:
> KaiGai Kohei wrote:
> > In summary, it was similar approach with what I already proposed
> > in the CF#2, but rejected.
> >
> > During the first commit-fest of v8.5 development cycle, Stephen
> > Frost suggested to rework the default
KaiGai Kohei wrote:
> In summary, it was similar approach with what I already proposed in the CF#2,
> but rejected.
>
> During the first commit-fest of v8.5 development cycle, Stephen Frost
> suggested
> to rework the default PG's access controls to host other optional security
> features, not on
Itagaki Takahiro wrote:
> KaiGai Kohei wrote:
>> -- keep it smaller, and step-by-step enhancement
>
> I'd prefer "smaller concept" rather than "smaller patch".
For the last a few days, I've talked with Itagaki-san off list to make clear
where is the point of his suggestion.
In summary, it was
On Thu, Nov 26, 2009 at 11:15:46AM +0900, Itagaki Takahiro wrote:
> No interaction with existing features
> * SE-PgSQL injects security-context-based access control, but there are
> no interaction between it and the existing role-based access control.
And there shouldn't be, I think. S
Itagaki Takahiro wrote:
> KaiGai Kohei wrote:
>> -- keep it smaller, and step-by-step enhancement
>
> I'd prefer "smaller concept" rather than "smaller patch".
Its difference is unclear for me.
In this CF, I separated most of separatable concepts to reduce
size of the patch, as follows:
- No
KaiGai Kohei wrote:
> -- keep it smaller, and step-by-step enhancement
I'd prefer "smaller concept" rather than "smaller patch".
I think the philosophy of SE-PgSQL itself is ok,
but there are some issues in the design and implementation:
No interaction with existing features
* SE-P
2009/11/24 KaiGai Kohei :
> BTW, I plan the following steps for the row-level security.
> | * A facility to put "security label OID" within the tuple header.
> | * System column support to print out the security context.
> | (This system column shall be writable to relabel)
> | * Pure-SQL row-lev
Itagaki Takahiro wrote:
KaiGai Kohei wrote:
Internal structures
http://wiki.postgresql.org/wiki/SEPostgreSQL_Architecture#Interaction_between_pg_security_system_catalog
In SELinux model, massive number of objects shares a limited number of
security context (e.g more than 100 tables
KaiGai Kohei wrote:
> >>> Internal structures
> http://wiki.postgresql.org/wiki/SEPostgreSQL_Architecture#Interaction_between_pg_security_system_catalog
>
> In SELinux model, massive number of objects shares a limited number of
> security context (e.g more than 100 tables may have a s
* It uses dedicated 'SExxx' error codes, but I think they should belong to
the same family of ERRCODE_INSUFFICIENT_PRIVILEGE (42501).
>>> I already uses predefined error code, if exist.
>> What I meant was: there are no problem to add new error codes for SE-PgSQL,
>> but I think the val
Itagaki Takahiro wrote:
> KaiGai Kohei wrote:
>
>>> CREATE TABLE tbl (...) SECURITY CONTEXT '...'
>>> * CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...')
>> We need to put a reserved token, such as "AS", prior to the SECURITY_CONTEXT
>> to avoid syntax conflicts to "DEFAULT b_expr" opt
KaiGai Kohei wrote:
> > CREATE TABLE tbl (...) SECURITY CONTEXT '...'
> > * CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...')
>
> We need to put a reserved token, such as "AS", prior to the SECURITY_CONTEXT
> to avoid syntax conflicts to "DEFAULT b_expr" option.
There might be anoth
KaiGai Kohei wrote:
> Ross J. Reedstrom wrote:
>> On Tue, Nov 24, 2009 at 03:12:43PM +0900, KaiGai Kohei wrote:
>>> Itagaki Takahiro wrote:
* CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...')
Is the syntax " SECURITY_CONTEXT" natural in English?
>>> We need to put a reserved to
Ross J. Reedstrom wrote:
On Tue, Nov 24, 2009 at 03:12:43PM +0900, KaiGai Kohei wrote:
Itagaki Takahiro wrote:
* CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...')
Is the syntax " SECURITY_CONTEXT" natural in English?
We need to put a reserved token, such as "AS", prior to the SECURI
On Tue, Nov 24, 2009 at 03:12:43PM +0900, KaiGai Kohei wrote:
> Itagaki Takahiro wrote:
> > * CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...')
> > Is the syntax " SECURITY_CONTEXT" natural in English?
>
> We need to put a reserved token, such as "AS", prior to the SECURITY_CONTEXT
> to
>> * Can we use error messages that looks like existing privilege errors?
>>ERRCODE_INSUFFICIENT_PRIVILEGE:
>> => permission denied to rename database
>
> Here is a point that we should provide users a hint which enables
> to make clear the reason of access violations. So, I think we shou
Itagaki Takahiro wrote:
> I'm reviewing SE-PgSQL patch and have some comments.
> https://commitfest.postgresql.org/action/patch_view?id=212
>
> Forgive me, but I'm a novice of SELinux. Some of the comments
> and question might be nonsense.
Itagaki-san, thanks for your volunteering so much!
> ===
I'm reviewing SE-PgSQL patch and have some comments.
https://commitfest.postgresql.org/action/patch_view?id=212
Forgive me, but I'm a novice of SELinux. Some of the comments
and question might be nonsense.
Patch overview
The patch itself is large (>13K), but more than half of it are
wel
35 matches
Mail list logo
