Re: One question about security label command

On Sun, May 10, 2015 at 3:15 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
> 2015-05-01 9:52 GMT+09:00 Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>:
>> 2015-05-01 7:40 GMT+09:00 Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>:
>>> Kouhei Kaigai wrote:
>>>> > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>>>> > > The idea of making the regression test entirely independent of the
>>>> > > system's policy would presumably solve this problem, so I'd kind of
>>>> > > like to see progress on that front.
>>>> >
>>>> > Apologies, I guess it wasn't clear, but that's what I was intending to
>>>> > advocate.
>>>> >
>>>> OK, I'll try to design a new regression test policy that is independent
>>>> from the system's policy assumption, like unconfined domain.
>>>>
>>>> Please give me time for this work.
>>>
>>> Any progress here?
>>>
>> Not done.
>> The last version I rebuild had a trouble on user/role transition from
>> unconfined_u/unconfined_r to the self defined user/role...
>> So, I'm trying to keep the user/role field (that is not redefined for
>> several years) but to define self domain/types (that have been
>> redefined multiple times) for the regression test at this moment.
>>
> The second approach above works.
> I defined a own privileged domain (sepgsql_regtest_superuser_t)
> instead of system's unconfined_t domain.
> The reason why regression test gets failed was, definition of
> unconfined_t in the system default policy was changed to bypass
> multi-category rules; which our regression test depends on.
> So, the new sepgsql_regtest_superuser_t domain performs almost
> like as unconfined_t, but restricted by multi-category policy as
> traditional unconfined_t did.
> It is self defined domain, so will not affected by system policy
> change.
> Even though the sepgsql-regtest.te still uses unconfined_u and
> unconfined_r pair for selinux-user and role, it requires users to
> define additional selinux-user by hand if we try to define own one.
> In addition, its definition has not been changed for several years.
> So, I thought it has less risk to rely on unconfined_u/unconfined_r
> field unlike unconfined_t domain.

Can you add this to the next CommitFest?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company