[refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)

[refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)

[KaiGai Kohei]

(2010/04/08 21:15), Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> As Dominick stated.  I prefer to think in terms of two different roles.
>   Login Roles, and Roles to execute in when you have privileges (IE Root).
> 
> Login Roles/Types
> staff_t, user_t, unconfined_t, xguest_t, guest_t
> 
> Three interfaces can be used to create confined login users.
> 
> userdom_restricted_user_template(guest)
> userdom_restricted_xwindows_user_template(xguest)
> userdom_unpriv_user_template(staff)
> 
> 
> Admin Roles/Types
> logadm_t, webadm_t, secadm_t, auditadm_t
> 
> The following interface can be used to create an Admin ROle
> userdom_base_user_template(logadm)
> 
> 
> sysadm_t is sort of a hybrid, most people use it as an Admin Role.
> 
> 
> I imagine that you login as a confined user and then use sudo/newrole to
> switch roles to one of the admin roles.

The attached patch revises roles/dbadm.te (to be applied on the upstream
reference policy). It uses userdom_base_user_template() instead of the
userdom_unpriv_user_template(), and should be launched via sudo/newrole.
In the default, it intends the dbadm_r role to be launched by staff_r role.

What I did)
[root at saba ~]# semodule -i ~kaigai/repo/refpolicy/policy/modules/roles/dbadm.pp
[root at saba ~]# semanage user -m -P user -r s0-s0:c0.c1023 -R "dbadm_r staff_r system_r" ymj_u
[root at saba ~]# semanage login -a -s ymj_u ymj

[root at saba ~]# echo "ymj ALL=(ALL) TYPE=dbadm_t ROLE=dbadm_r NOPASSWD:/sbin/service" >> /etc/sudoers

[root at saba ~]# cp /etc/selinux/targeted/contexts/users/staff_u \
                  /etc/selinux/targeted/contexts/users/ymj_u

[root at saba ~]# semanage user -l

                Labeling   MLS/       MLS/
SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles

guest_u         user       s0         s0                             guest_r
root            user       s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r unconfined_r
staff_u         user       s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r unconfined_r
sysadm_u        user       s0         s0-s0:c0.c1023                 sysadm_r
system_u        user       s0         s0-s0:c0.c1023                 system_r unconfined_r
unconfined_u    user       s0         s0-s0:c0.c1023                 system_r unconfined_r
user_u          user       s0         s0                             user_r
webadm_u        user       s0         s0                             webadm_r
xguest_u        user       s0         s0                             xguest_r
ymj_u           user       s0         s0-s0:c0.c1023                 dbadm_r staff_r system_r
[root at saba ~]# semanage login -l

Login Name                SELinux User              MLS/MCS Range

__default__               unconfined_u              s0-s0:c0.c1023
root                      unconfined_u              s0-s0:c0.c1023
system_u                  system_u                  s0-s0:c0.c1023
ymj                       ymj_u                     s0

[root at saba ~]# ssh ymj at localhost
ymj at localhost's password:
Last login: Fri Apr  9 13:59:32 2010 from localhost
[ymj at saba ~]$ id -Z
ymj_u:staff_r:staff_t:s0

[ymj at saba ~]$ sudo service sepostgresql restart
Stopping sepostgresql service:                             [  OK  ]
Starting sepostgresql service:                             [  OK  ]

[ymj at saba ~]$ ps -AZ | grep sepostgres
ymj_u:system_r:postgresql_t:s0   1171 ?        00:00:01 sepostgres
ymj_u:system_r:postgresql_t:s0   1176 ?        00:00:00 sepostgres
ymj_u:system_r:postgresql_t:s0   1177 ?        00:00:00 sepostgres
ymj_u:system_r:postgresql_t:s0   1178 ?        00:00:00 sepostgres
ymj_u:system_r:postgresql_t:s0   1179 ?        00:00:00 sepostgres
ymj_u:system_r:postgresql_t:s0   1180 ?        00:00:00 sepostgres

[ymj at saba ~]$ newrole -r dbadm_r -t dbadm_t
Password:
[ymj at saba ~]$ psql postgres
psql (8.4.3, server 9.0alpha5)
WARNING: psql version 8.4, server version 9.0.
         Some psql features might not work.
Type "help" for help.

postgres=> SELECT sepgsql_getcon();
      sepgsql_getcon
--------------------------
 ymj_u:dbadm_r:dbadm_t:s0
(1 row)

postgres=> CREATE TABLE my_table (a int, b text);
CREATE TABLE
postgres=> SELECT * FROM my_table;
ERROR:  SELinux: security policy violation

> Of course you are free to design your own system creating fully login
> admin roles. Or creating addinitional non admin user roles.
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAku9yOUACgkQrlYvE4MpobNZBQCgh5RdBRm1ZPjtHNqI5Jf3UHRs
> Bw0An3cao7Jw/TJUiS6LqB5C6C5ajyhd
> =q1nL
> -----END PGP SIGNATURE-----
> --
> selinux mailing list
> selinux at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
> 


-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-dbadm-revise.1.patch
Type: text/x-patch
Size: 1827 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100409/b4a9094c/attachment.bin 

[refpolicy] [BUGFIX] lack of type transition on dbadm domain (Re: dbadm.pp is not available in selinux-policy package)

[KaiGai Kohei]

A corresponding problem.

I found out a bug when we initialize the database with dbadm_r:dbadm_t
which belongs to sepgsql_admin_type attribute.

In the case when sepgsql_admin_type create a new database objects,
it does not have valid type_transition rules. So, it was failed.
Sorry, I didn't find out it for a long time.

And db_procedure:{execute} on the sepgsql_proc_exec_t might be necessary
for the administrative domain independently from sepgsql_unconfined_dbadm,
because we need to execute some of system defined procedures to look up
system tables.

Thanks,

(2010/04/08 21:15), Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> As Dominick stated.  I prefer to think in terms of two different roles.
>   Login Roles, and Roles to execute in when you have privileges (IE Root).
> 
> Login Roles/Types
> staff_t, user_t, unconfined_t, xguest_t, guest_t
> 
> Three interfaces can be used to create confined login users.
> 
> userdom_restricted_user_template(guest)
> userdom_restricted_xwindows_user_template(xguest)
> userdom_unpriv_user_template(staff)
> 
> 
> Admin Roles/Types
> logadm_t, webadm_t, secadm_t, auditadm_t
> 
> The following interface can be used to create an Admin ROle
> userdom_base_user_template(logadm)
> 
> 
> sysadm_t is sort of a hybrid, most people use it as an Admin Role.
> 
> 
> I imagine that you login as a confined user and then use sudo/newrole to
> switch roles to one of the admin roles.
> 
> Of course you are free to design your own system creating fully login
> admin roles. Or creating addinitional non admin user roles.
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAku9yOUACgkQrlYvE4MpobNZBQCgh5RdBRm1ZPjtHNqI5Jf3UHRs
> Bw0An3cao7Jw/TJUiS6LqB5C6C5ajyhd
> =q1nL
> -----END PGP SIGNATURE-----
> --
> selinux mailing list
> selinux at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
> 


-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-pgsql-fixes.1.patch
Type: text/x-patch
Size: 1379 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100409/6369d3e6/attachment.bin 

[refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)

[Christopher J. PeBenito]

On Fri, 2010-04-09 at 14:29 +0900, KaiGai Kohei wrote:
> (2010/04/08 21:15), Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > As Dominick stated.  I prefer to think in terms of two different roles.
> >   Login Roles, and Roles to execute in when you have privileges (IE Root).
> > 
> > Login Roles/Types
> > staff_t, user_t, unconfined_t, xguest_t, guest_t
> > 
> > Three interfaces can be used to create confined login users.
> > 
> > userdom_restricted_user_template(guest)
> > userdom_restricted_xwindows_user_template(xguest)
> > userdom_unpriv_user_template(staff)
> > 
> > 
> > Admin Roles/Types
> > logadm_t, webadm_t, secadm_t, auditadm_t
> > 
> > The following interface can be used to create an Admin ROle
> > userdom_base_user_template(logadm)
> > 
> > 
> > sysadm_t is sort of a hybrid, most people use it as an Admin Role.
> > 
> > 
> > I imagine that you login as a confined user and then use sudo/newrole to
> > switch roles to one of the admin roles.
> 
> The attached patch revises roles/dbadm.te (to be applied on the upstream
> reference policy). It uses userdom_base_user_template() instead of the
> userdom_unpriv_user_template(), and should be launched via sudo/newrole.
> In the default, it intends the dbadm_r role to be launched by staff_r role.

Why does dbadm need to run setfiles?

Use of staff_role_change_to() is not allowed upstream.  If staff should
be allowed to change to dbadm, the dbadm_role_change() should be used in
the staff module.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] [BUGFIX] lack of type transition on dbadm domain (Re: dbadm.pp is not available in selinux-policy package)

[Christopher J. PeBenito]

On Fri, 2010-04-09 at 14:40 +0900, KaiGai Kohei wrote:
> A corresponding problem.
> 
> I found out a bug when we initialize the database with dbadm_r:dbadm_t
> which belongs to sepgsql_admin_type attribute.
> 
> In the case when sepgsql_admin_type create a new database objects,
> it does not have valid type_transition rules. So, it was failed.
> Sorry, I didn't find out it for a long time.
> 
> And db_procedure:{execute} on the sepgsql_proc_exec_t might be necessary
> for the administrative domain independently from sepgsql_unconfined_dbadm,
> because we need to execute some of system defined procedures to look up
> system tables.

Merged.  In the future, please do not increment the module version as
part of your patch.

> (2010/04/08 21:15), Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > As Dominick stated.  I prefer to think in terms of two different roles.
> >   Login Roles, and Roles to execute in when you have privileges (IE Root).
> > 
> > Login Roles/Types
> > staff_t, user_t, unconfined_t, xguest_t, guest_t
> > 
> > Three interfaces can be used to create confined login users.
> > 
> > userdom_restricted_user_template(guest)
> > userdom_restricted_xwindows_user_template(xguest)
> > userdom_unpriv_user_template(staff)
> > 
> > 
> > Admin Roles/Types
> > logadm_t, webadm_t, secadm_t, auditadm_t
> > 
> > The following interface can be used to create an Admin ROle
> > userdom_base_user_template(logadm)
> > 
> > 
> > sysadm_t is sort of a hybrid, most people use it as an Admin Role.
> > 
> > 
> > I imagine that you login as a confined user and then use sudo/newrole to
> > switch roles to one of the admin roles.
> > 
> > Of course you are free to design your own system creating fully login
> > admin roles. Or creating addinitional non admin user roles.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)

[KaiGai Kohei]

(2010/04/12 23:09), Christopher J. PeBenito wrote:
> On Fri, 2010-04-09 at 14:29 +0900, KaiGai Kohei wrote:
>> (2010/04/08 21:15), Daniel J Walsh wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> As Dominick stated.  I prefer to think in terms of two different roles.
>>>    Login Roles, and Roles to execute in when you have privileges (IE Root).
>>>
>>> Login Roles/Types
>>> staff_t, user_t, unconfined_t, xguest_t, guest_t
>>>
>>> Three interfaces can be used to create confined login users.
>>>
>>> userdom_restricted_user_template(guest)
>>> userdom_restricted_xwindows_user_template(xguest)
>>> userdom_unpriv_user_template(staff)
>>>
>>>
>>> Admin Roles/Types
>>> logadm_t, webadm_t, secadm_t, auditadm_t
>>>
>>> The following interface can be used to create an Admin ROle
>>> userdom_base_user_template(logadm)
>>>
>>>
>>> sysadm_t is sort of a hybrid, most people use it as an Admin Role.
>>>
>>>
>>> I imagine that you login as a confined user and then use sudo/newrole to
>>> switch roles to one of the admin roles.
>>
>> The attached patch revises roles/dbadm.te (to be applied on the upstream
>> reference policy). It uses userdom_base_user_template() instead of the
>> userdom_unpriv_user_template(), and should be launched via sudo/newrole.
>> In the default, it intends the dbadm_r role to be launched by staff_r role.
> 
> Why does dbadm need to run setfiles?

The database files (typically, /var/lib/(se)?pgsql/*) have to be labeled
correctly, so I thought dbadm needs to run setfiles.
However, as long as they initialize database files using init script,
initrc_t domain performs this initial labeling, so it might not be necessary.

On the other hand, PostgreSQL support a feature to use multiple disks
within a single database instance for performance utilization.
(Called TABLESPACE; I don't know whether MySQL has such a feature.)

http://archives.postgresql.org/pgsql-general/2006-08/msg00142.php

It requires administrators to assign proper security context on the secondary
directory, or to mount the secondary disk with context='...' option.

Is there any good idea?

Or, it should not be a task for dbadm?

> Use of staff_role_change_to() is not allowed upstream.  If staff should
> be allowed to change to dbadm, the dbadm_role_change() should be used in
> the staff module.

OK, I'll fix it.

Thanks,
-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>

[refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)

[Christopher J. PeBenito]

On Tue, 2010-04-13 at 09:28 +0900, KaiGai Kohei wrote:
> (2010/04/12 23:09), Christopher J. PeBenito wrote:
> > On Fri, 2010-04-09 at 14:29 +0900, KaiGai Kohei wrote:
> >> (2010/04/08 21:15), Daniel J Walsh wrote:
> >>> As Dominick stated.  I prefer to think in terms of two different roles.
> >>>    Login Roles, and Roles to execute in when you have privileges (IE Root).
> >>>
> >>> Login Roles/Types
> >>> staff_t, user_t, unconfined_t, xguest_t, guest_t
> >>>
> >>> Three interfaces can be used to create confined login users.
> >>>
> >>> userdom_restricted_user_template(guest)
> >>> userdom_restricted_xwindows_user_template(xguest)
> >>> userdom_unpriv_user_template(staff)
> >>>
> >>>
> >>> Admin Roles/Types
> >>> logadm_t, webadm_t, secadm_t, auditadm_t
> >>>
> >>> The following interface can be used to create an Admin ROle
> >>> userdom_base_user_template(logadm)
> >>>
> >>>
> >>> sysadm_t is sort of a hybrid, most people use it as an Admin Role.
> >>>
> >>>
> >>> I imagine that you login as a confined user and then use sudo/newrole to
> >>> switch roles to one of the admin roles.
> >>
> >> The attached patch revises roles/dbadm.te (to be applied on the upstream
> >> reference policy). It uses userdom_base_user_template() instead of the
> >> userdom_unpriv_user_template(), and should be launched via sudo/newrole.
> >> In the default, it intends the dbadm_r role to be launched by staff_r role.
> > 
> > Why does dbadm need to run setfiles?
> 
> The database files (typically, /var/lib/(se)?pgsql/*) have to be labeled
> correctly, so I thought dbadm needs to run setfiles.
> However, as long as they initialize database files using init script,
> initrc_t domain performs this initial labeling, so it might not be necessary.
> 
> On the other hand, PostgreSQL support a feature to use multiple disks
> within a single database instance for performance utilization.
> (Called TABLESPACE; I don't know whether MySQL has such a feature.)
> 
> http://archives.postgresql.org/pgsql-general/2006-08/msg00142.php
> 
> It requires administrators to assign proper security context on the secondary
> directory, or to mount the secondary disk with context='...' option.
> 
> Is there any good idea?
> 
> Or, it should not be a task for dbadm?

Ok, the transition for setfiles is fine.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/13/2010 09:17 AM, Christopher J. PeBenito wrote:
> On Tue, 2010-04-13 at 09:28 +0900, KaiGai Kohei wrote:
>> (2010/04/12 23:09), Christopher J. PeBenito wrote:
>>> On Fri, 2010-04-09 at 14:29 +0900, KaiGai Kohei wrote:
>>>> (2010/04/08 21:15), Daniel J Walsh wrote:
>>>>> As Dominick stated.  I prefer to think in terms of two different roles.
>>>>>    Login Roles, and Roles to execute in when you have privileges (IE Root).
>>>>>
>>>>> Login Roles/Types
>>>>> staff_t, user_t, unconfined_t, xguest_t, guest_t
>>>>>
>>>>> Three interfaces can be used to create confined login users.
>>>>>
>>>>> userdom_restricted_user_template(guest)
>>>>> userdom_restricted_xwindows_user_template(xguest)
>>>>> userdom_unpriv_user_template(staff)
>>>>>
>>>>>
>>>>> Admin Roles/Types
>>>>> logadm_t, webadm_t, secadm_t, auditadm_t
>>>>>
>>>>> The following interface can be used to create an Admin ROle
>>>>> userdom_base_user_template(logadm)
>>>>>
>>>>>
>>>>> sysadm_t is sort of a hybrid, most people use it as an Admin Role.
>>>>>
>>>>>
>>>>> I imagine that you login as a confined user and then use sudo/newrole to
>>>>> switch roles to one of the admin roles.
>>>>
>>>> The attached patch revises roles/dbadm.te (to be applied on the upstream
>>>> reference policy). It uses userdom_base_user_template() instead of the
>>>> userdom_unpriv_user_template(), and should be launched via sudo/newrole.
>>>> In the default, it intends the dbadm_r role to be launched by staff_r role.
>>>
>>> Why does dbadm need to run setfiles?
>>
>> The database files (typically, /var/lib/(se)?pgsql/*) have to be labeled
>> correctly, so I thought dbadm needs to run setfiles.
>> However, as long as they initialize database files using init script,
>> initrc_t domain performs this initial labeling, so it might not be necessary.
>>
>> On the other hand, PostgreSQL support a feature to use multiple disks
>> within a single database instance for performance utilization.
>> (Called TABLESPACE; I don't know whether MySQL has such a feature.)
>>
>> http://archives.postgresql.org/pgsql-general/2006-08/msg00142.php
>>
>> It requires administrators to assign proper security context on the secondary
>> directory, or to mount the secondary disk with context='...' option.
>>
>> Is there any good idea?
>>
>> Or, it should not be a task for dbadm?
> 
> Ok, the transition for setfiles is fine.
> 

I would be carefull with this.  Since setfiles can take a parameter of a
file context file.  I think it would be better to only give
relabefrom/relabelto privs for all labels dbadm_t can manage.  Then
figure out what access is required to mount.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkvEioAACgkQrlYvE4MpobPgIwCgtK9sqyPvRhj90hfQFZU+ZlpJ
H6UAoIrrEMw2dv/1/QR9Oi/J1iXBhqrx
=dfmE
-----END PGP SIGNATURE-----

[refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)

[Christopher J. PeBenito]

On Tue, 2010-04-13 at 11:15 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 04/13/2010 09:17 AM, Christopher J. PeBenito wrote:
> > On Tue, 2010-04-13 at 09:28 +0900, KaiGai Kohei wrote:
> >> (2010/04/12 23:09), Christopher J. PeBenito wrote:
> >>> On Fri, 2010-04-09 at 14:29 +0900, KaiGai Kohei wrote:
> >>>> (2010/04/08 21:15), Daniel J Walsh wrote:
> >>>>> As Dominick stated.  I prefer to think in terms of two different roles.
> >>>>>    Login Roles, and Roles to execute in when you have privileges (IE Root).
> >>>>>
> >>>>> Login Roles/Types
> >>>>> staff_t, user_t, unconfined_t, xguest_t, guest_t
> >>>>>
> >>>>> Three interfaces can be used to create confined login users.
> >>>>>
> >>>>> userdom_restricted_user_template(guest)
> >>>>> userdom_restricted_xwindows_user_template(xguest)
> >>>>> userdom_unpriv_user_template(staff)
> >>>>>
> >>>>>
> >>>>> Admin Roles/Types
> >>>>> logadm_t, webadm_t, secadm_t, auditadm_t
> >>>>>
> >>>>> The following interface can be used to create an Admin ROle
> >>>>> userdom_base_user_template(logadm)
> >>>>>
> >>>>>
> >>>>> sysadm_t is sort of a hybrid, most people use it as an Admin Role.
> >>>>>
> >>>>>
> >>>>> I imagine that you login as a confined user and then use sudo/newrole to
> >>>>> switch roles to one of the admin roles.
> >>>>
> >>>> The attached patch revises roles/dbadm.te (to be applied on the upstream
> >>>> reference policy). It uses userdom_base_user_template() instead of the
> >>>> userdom_unpriv_user_template(), and should be launched via sudo/newrole.
> >>>> In the default, it intends the dbadm_r role to be launched by staff_r role.
> >>>
> >>> Why does dbadm need to run setfiles?
> >>
> >> The database files (typically, /var/lib/(se)?pgsql/*) have to be labeled
> >> correctly, so I thought dbadm needs to run setfiles.
> >> However, as long as they initialize database files using init script,
> >> initrc_t domain performs this initial labeling, so it might not be necessary.
> >>
> >> On the other hand, PostgreSQL support a feature to use multiple disks
> >> within a single database instance for performance utilization.
> >> (Called TABLESPACE; I don't know whether MySQL has such a feature.)
> >>
> >> http://archives.postgresql.org/pgsql-general/2006-08/msg00142.php
> >>
> >> It requires administrators to assign proper security context on the secondary
> >> directory, or to mount the secondary disk with context='...' option.
> >>
> >> Is there any good idea?
> >>
> >> Or, it should not be a task for dbadm?
> > 
> > Ok, the transition for setfiles is fine.
> > 
> 
> I would be carefull with this.  Since setfiles can take a parameter of a
> file context file.  I think it would be better to only give
> relabefrom/relabelto privs for all labels dbadm_t can manage.  Then
> figure out what access is required to mount.

Good point.  We should probably reconsider the setfiles usage from
webadm too.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)

[KaiGai Kohei]

(2010/04/14 0:57), Christopher J. PeBenito wrote:
> On Tue, 2010-04-13 at 11:15 -0400, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 04/13/2010 09:17 AM, Christopher J. PeBenito wrote:
>>> On Tue, 2010-04-13 at 09:28 +0900, KaiGai Kohei wrote:
>>>> (2010/04/12 23:09), Christopher J. PeBenito wrote:
>>>>> On Fri, 2010-04-09 at 14:29 +0900, KaiGai Kohei wrote:
>>>>>> (2010/04/08 21:15), Daniel J Walsh wrote:
>>>>>>> As Dominick stated.  I prefer to think in terms of two different roles.
>>>>>>>     Login Roles, and Roles to execute in when you have privileges (IE Root).
>>>>>>>
>>>>>>> Login Roles/Types
>>>>>>> staff_t, user_t, unconfined_t, xguest_t, guest_t
>>>>>>>
>>>>>>> Three interfaces can be used to create confined login users.
>>>>>>>
>>>>>>> userdom_restricted_user_template(guest)
>>>>>>> userdom_restricted_xwindows_user_template(xguest)
>>>>>>> userdom_unpriv_user_template(staff)
>>>>>>>
>>>>>>>
>>>>>>> Admin Roles/Types
>>>>>>> logadm_t, webadm_t, secadm_t, auditadm_t
>>>>>>>
>>>>>>> The following interface can be used to create an Admin ROle
>>>>>>> userdom_base_user_template(logadm)
>>>>>>>
>>>>>>>
>>>>>>> sysadm_t is sort of a hybrid, most people use it as an Admin Role.
>>>>>>>
>>>>>>>
>>>>>>> I imagine that you login as a confined user and then use sudo/newrole to
>>>>>>> switch roles to one of the admin roles.
>>>>>>
>>>>>> The attached patch revises roles/dbadm.te (to be applied on the upstream
>>>>>> reference policy). It uses userdom_base_user_template() instead of the
>>>>>> userdom_unpriv_user_template(), and should be launched via sudo/newrole.
>>>>>> In the default, it intends the dbadm_r role to be launched by staff_r role.
>>>>>
>>>>> Why does dbadm need to run setfiles?
>>>>
>>>> The database files (typically, /var/lib/(se)?pgsql/*) have to be labeled
>>>> correctly, so I thought dbadm needs to run setfiles.
>>>> However, as long as they initialize database files using init script,
>>>> initrc_t domain performs this initial labeling, so it might not be necessary.
>>>>
>>>> On the other hand, PostgreSQL support a feature to use multiple disks
>>>> within a single database instance for performance utilization.
>>>> (Called TABLESPACE; I don't know whether MySQL has such a feature.)
>>>>
>>>> http://archives.postgresql.org/pgsql-general/2006-08/msg00142.php
>>>>
>>>> It requires administrators to assign proper security context on the secondary
>>>> directory, or to mount the secondary disk with context='...' option.
>>>>
>>>> Is there any good idea?
>>>>
>>>> Or, it should not be a task for dbadm?
>>>
>>> Ok, the transition for setfiles is fine.
>>>
>>
>> I would be carefull with this.  Since setfiles can take a parameter of a
>> file context file.  I think it would be better to only give
>> relabefrom/relabelto privs for all labels dbadm_t can manage.  Then
>> figure out what access is required to mount.
> 
> Good point.  We should probably reconsider the setfiles usage from
> webadm too.

The attached patch is a revised one.
- seutil_domtrans_setfiles() was removed
- staff_role_change_to() was removed, and I put dbadm_role_change()
  on the staff.te
- Fix an obvious typo.

It is not clear for me whether the idea to allow relabelfrom/relabelto
for all the files dbadm_t can manage, because it is eventually necessary
someone to relabel (or assign initial labels) files from unlabeled one
to managed labels when we mount a new disk.

If so, should it be a task of sysadm_t to mount new disk and assign
security context correctly, instead of webadm_t/dbadm_t?

Thanks,
-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-dbadm-revise.2.patch
Type: text/x-patch
Size: 2419 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100415/29aa392d/attachment.bin 

[refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/15/2010 02:02 AM, KaiGai Kohei wrote:
> (2010/04/14 0:57), Christopher J. PeBenito wrote:
>> On Tue, 2010-04-13 at 11:15 -0400, Daniel J Walsh wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 04/13/2010 09:17 AM, Christopher J. PeBenito wrote:
>>>> On Tue, 2010-04-13 at 09:28 +0900, KaiGai Kohei wrote:
>>>>> (2010/04/12 23:09), Christopher J. PeBenito wrote:
>>>>>> On Fri, 2010-04-09 at 14:29 +0900, KaiGai Kohei wrote:
>>>>>>> (2010/04/08 21:15), Daniel J Walsh wrote:
>>>>>>>> As Dominick stated.  I prefer to think in terms of two different roles.
>>>>>>>>     Login Roles, and Roles to execute in when you have privileges (IE Root).
>>>>>>>>
>>>>>>>> Login Roles/Types
>>>>>>>> staff_t, user_t, unconfined_t, xguest_t, guest_t
>>>>>>>>
>>>>>>>> Three interfaces can be used to create confined login users.
>>>>>>>>
>>>>>>>> userdom_restricted_user_template(guest)
>>>>>>>> userdom_restricted_xwindows_user_template(xguest)
>>>>>>>> userdom_unpriv_user_template(staff)
>>>>>>>>
>>>>>>>>
>>>>>>>> Admin Roles/Types
>>>>>>>> logadm_t, webadm_t, secadm_t, auditadm_t
>>>>>>>>
>>>>>>>> The following interface can be used to create an Admin ROle
>>>>>>>> userdom_base_user_template(logadm)
>>>>>>>>
>>>>>>>>
>>>>>>>> sysadm_t is sort of a hybrid, most people use it as an Admin Role.
>>>>>>>>
>>>>>>>>
>>>>>>>> I imagine that you login as a confined user and then use sudo/newrole to
>>>>>>>> switch roles to one of the admin roles.
>>>>>>>
>>>>>>> The attached patch revises roles/dbadm.te (to be applied on the upstream
>>>>>>> reference policy). It uses userdom_base_user_template() instead of the
>>>>>>> userdom_unpriv_user_template(), and should be launched via sudo/newrole.
>>>>>>> In the default, it intends the dbadm_r role to be launched by staff_r role.
>>>>>>
>>>>>> Why does dbadm need to run setfiles?
>>>>>
>>>>> The database files (typically, /var/lib/(se)?pgsql/*) have to be labeled
>>>>> correctly, so I thought dbadm needs to run setfiles.
>>>>> However, as long as they initialize database files using init script,
>>>>> initrc_t domain performs this initial labeling, so it might not be necessary.
>>>>>
>>>>> On the other hand, PostgreSQL support a feature to use multiple disks
>>>>> within a single database instance for performance utilization.
>>>>> (Called TABLESPACE; I don't know whether MySQL has such a feature.)
>>>>>
>>>>> http://archives.postgresql.org/pgsql-general/2006-08/msg00142.php
>>>>>
>>>>> It requires administrators to assign proper security context on the secondary
>>>>> directory, or to mount the secondary disk with context='...' option.
>>>>>
>>>>> Is there any good idea?
>>>>>
>>>>> Or, it should not be a task for dbadm?
>>>>
>>>> Ok, the transition for setfiles is fine.
>>>>
>>>
>>> I would be carefull with this.  Since setfiles can take a parameter of a
>>> file context file.  I think it would be better to only give
>>> relabefrom/relabelto privs for all labels dbadm_t can manage.  Then
>>> figure out what access is required to mount.
>>
>> Good point.  We should probably reconsider the setfiles usage from
>> webadm too.
> 
> The attached patch is a revised one.
> - seutil_domtrans_setfiles() was removed
> - staff_role_change_to() was removed, and I put dbadm_role_change()
>   on the staff.te
> - Fix an obvious typo.
> 
> It is not clear for me whether the idea to allow relabelfrom/relabelto
> for all the files dbadm_t can manage, because it is eventually necessary
> someone to relabel (or assign initial labels) files from unlabeled one
> to managed labels when we mount a new disk.
> 
> If so, should it be a task of sysadm_t to mount new disk and assign
> security context correctly, instead of webadm_t/dbadm_t?
> 
I guess I would argue that the ability to mount a device can not be
allowed to a confined administrator by default.   Since giving the
ability to mount, allows the confined administrator and easy mechanism
to break out of his confinement.

mount -o bind mypasswd /etc/passwd  for example.

I think mounting should be left to the sysadm_t/unconfined_t.  If the
sysadm_t/unconfined_t wants to setup certain disks that can be mounted
by the dbadm_t then he would either need to write a script and add
policy for that script or write policy to allow the dbadm_t to
transition to mount_t.
> Thanks,
> 
> 
> 
> --
> selinux mailing list
> selinux at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkvHDGsACgkQrlYvE4MpobP4TwCcCUBCw8yaoLAuSkmLtfQlytgh
wxMAoKCfnHr+/BwUX0ep+XzblvYn/jjn
=+Cf6
-----END PGP SIGNATURE-----

[refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)

[KaiGai Kohei]

(2010/04/15 21:54), Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04/15/2010 02:02 AM, KaiGai Kohei wrote:
>> (2010/04/14 0:57), Christopher J. PeBenito wrote:
>>> On Tue, 2010-04-13 at 11:15 -0400, Daniel J Walsh wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 04/13/2010 09:17 AM, Christopher J. PeBenito wrote:
>>>>> On Tue, 2010-04-13 at 09:28 +0900, KaiGai Kohei wrote:
>>>>>> (2010/04/12 23:09), Christopher J. PeBenito wrote:
>>>>>>> On Fri, 2010-04-09 at 14:29 +0900, KaiGai Kohei wrote:
>>>>>>>> (2010/04/08 21:15), Daniel J Walsh wrote:
>>>>>>>>> As Dominick stated.  I prefer to think in terms of two different roles.
>>>>>>>>>      Login Roles, and Roles to execute in when you have privileges (IE Root).
>>>>>>>>>
>>>>>>>>> Login Roles/Types
>>>>>>>>> staff_t, user_t, unconfined_t, xguest_t, guest_t
>>>>>>>>>
>>>>>>>>> Three interfaces can be used to create confined login users.
>>>>>>>>>
>>>>>>>>> userdom_restricted_user_template(guest)
>>>>>>>>> userdom_restricted_xwindows_user_template(xguest)
>>>>>>>>> userdom_unpriv_user_template(staff)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Admin Roles/Types
>>>>>>>>> logadm_t, webadm_t, secadm_t, auditadm_t
>>>>>>>>>
>>>>>>>>> The following interface can be used to create an Admin ROle
>>>>>>>>> userdom_base_user_template(logadm)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> sysadm_t is sort of a hybrid, most people use it as an Admin Role.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I imagine that you login as a confined user and then use sudo/newrole to
>>>>>>>>> switch roles to one of the admin roles.
>>>>>>>>
>>>>>>>> The attached patch revises roles/dbadm.te (to be applied on the upstream
>>>>>>>> reference policy). It uses userdom_base_user_template() instead of the
>>>>>>>> userdom_unpriv_user_template(), and should be launched via sudo/newrole.
>>>>>>>> In the default, it intends the dbadm_r role to be launched by staff_r role.
>>>>>>>
>>>>>>> Why does dbadm need to run setfiles?
>>>>>>
>>>>>> The database files (typically, /var/lib/(se)?pgsql/*) have to be labeled
>>>>>> correctly, so I thought dbadm needs to run setfiles.
>>>>>> However, as long as they initialize database files using init script,
>>>>>> initrc_t domain performs this initial labeling, so it might not be necessary.
>>>>>>
>>>>>> On the other hand, PostgreSQL support a feature to use multiple disks
>>>>>> within a single database instance for performance utilization.
>>>>>> (Called TABLESPACE; I don't know whether MySQL has such a feature.)
>>>>>>
>>>>>> http://archives.postgresql.org/pgsql-general/2006-08/msg00142.php
>>>>>>
>>>>>> It requires administrators to assign proper security context on the secondary
>>>>>> directory, or to mount the secondary disk with context='...' option.
>>>>>>
>>>>>> Is there any good idea?
>>>>>>
>>>>>> Or, it should not be a task for dbadm?
>>>>>
>>>>> Ok, the transition for setfiles is fine.
>>>>>
>>>>
>>>> I would be carefull with this.  Since setfiles can take a parameter of a
>>>> file context file.  I think it would be better to only give
>>>> relabefrom/relabelto privs for all labels dbadm_t can manage.  Then
>>>> figure out what access is required to mount.
>>>
>>> Good point.  We should probably reconsider the setfiles usage from
>>> webadm too.
>>
>> The attached patch is a revised one.
>> - seutil_domtrans_setfiles() was removed
>> - staff_role_change_to() was removed, and I put dbadm_role_change()
>>    on the staff.te
>> - Fix an obvious typo.
>>
>> It is not clear for me whether the idea to allow relabelfrom/relabelto
>> for all the files dbadm_t can manage, because it is eventually necessary
>> someone to relabel (or assign initial labels) files from unlabeled one
>> to managed labels when we mount a new disk.
>>
>> If so, should it be a task of sysadm_t to mount new disk and assign
>> security context correctly, instead of webadm_t/dbadm_t?
>>
> I guess I would argue that the ability to mount a device can not be
> allowed to a confined administrator by default.   Since giving the
> ability to mount, allows the confined administrator and easy mechanism
> to break out of his confinement.
>
> mount -o bind mypasswd /etc/passwd  for example.
>
> I think mounting should be left to the sysadm_t/unconfined_t.  If the
> sysadm_t/unconfined_t wants to setup certain disks that can be mounted
> by the dbadm_t then he would either need to write a script and add
> policy for that script or write policy to allow the dbadm_t to
> transition to mount_t.

It seems to me fair enough. If confined administrators can mount disks
with their managing labels, it is equivalent to allow unconfined accesses.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

[refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)

[KaiGai Kohei]

Sorry for this long silent on the topic.

IIRC, we have already agreed most part of the patch, haven't we?

- The dbadm_t domain shall be launched via sudo, not a login shell,
  so, userdom_base_user_template() is used to grant basic privileges
  to dbadm_t instead of userdom_unpriv_user_template().
- It allows too much privileges to dbadm_t, if we allows him to launch
  setfiles, so we removed seutil_domtrans_setfiles().

Did we have any more issues?

The attached patch is same as the last version except for it was rebased
to the latest reference policy.

Thanks,

(2010/04/15 15:02), KaiGai Kohei wrote:
> (2010/04/14 0:57), Christopher J. PeBenito wrote:
>> On Tue, 2010-04-13 at 11:15 -0400, Daniel J Walsh wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 04/13/2010 09:17 AM, Christopher J. PeBenito wrote:
>>>> On Tue, 2010-04-13 at 09:28 +0900, KaiGai Kohei wrote:
>>>>> (2010/04/12 23:09), Christopher J. PeBenito wrote:
>>>>>> On Fri, 2010-04-09 at 14:29 +0900, KaiGai Kohei wrote:
>>>>>>> (2010/04/08 21:15), Daniel J Walsh wrote:
>>>>>>>> As Dominick stated.  I prefer to think in terms of two different roles.
>>>>>>>>      Login Roles, and Roles to execute in when you have privileges (IE Root).
>>>>>>>>
>>>>>>>> Login Roles/Types
>>>>>>>> staff_t, user_t, unconfined_t, xguest_t, guest_t
>>>>>>>>
>>>>>>>> Three interfaces can be used to create confined login users.
>>>>>>>>
>>>>>>>> userdom_restricted_user_template(guest)
>>>>>>>> userdom_restricted_xwindows_user_template(xguest)
>>>>>>>> userdom_unpriv_user_template(staff)
>>>>>>>>
>>>>>>>>
>>>>>>>> Admin Roles/Types
>>>>>>>> logadm_t, webadm_t, secadm_t, auditadm_t
>>>>>>>>
>>>>>>>> The following interface can be used to create an Admin ROle
>>>>>>>> userdom_base_user_template(logadm)
>>>>>>>>
>>>>>>>>
>>>>>>>> sysadm_t is sort of a hybrid, most people use it as an Admin Role.
>>>>>>>>
>>>>>>>>
>>>>>>>> I imagine that you login as a confined user and then use sudo/newrole to
>>>>>>>> switch roles to one of the admin roles.
>>>>>>>
>>>>>>> The attached patch revises roles/dbadm.te (to be applied on the upstream
>>>>>>> reference policy). It uses userdom_base_user_template() instead of the
>>>>>>> userdom_unpriv_user_template(), and should be launched via sudo/newrole.
>>>>>>> In the default, it intends the dbadm_r role to be launched by staff_r role.
>>>>>>
>>>>>> Why does dbadm need to run setfiles?
>>>>>
>>>>> The database files (typically, /var/lib/(se)?pgsql/*) have to be labeled
>>>>> correctly, so I thought dbadm needs to run setfiles.
>>>>> However, as long as they initialize database files using init script,
>>>>> initrc_t domain performs this initial labeling, so it might not be necessary.
>>>>>
>>>>> On the other hand, PostgreSQL support a feature to use multiple disks
>>>>> within a single database instance for performance utilization.
>>>>> (Called TABLESPACE; I don't know whether MySQL has such a feature.)
>>>>>
>>>>> http://archives.postgresql.org/pgsql-general/2006-08/msg00142.php
>>>>>
>>>>> It requires administrators to assign proper security context on the secondary
>>>>> directory, or to mount the secondary disk with context='...' option.
>>>>>
>>>>> Is there any good idea?
>>>>>
>>>>> Or, it should not be a task for dbadm?
>>>>
>>>> Ok, the transition for setfiles is fine.
>>>>
>>>
>>> I would be carefull with this.  Since setfiles can take a parameter of a
>>> file context file.  I think it would be better to only give
>>> relabefrom/relabelto privs for all labels dbadm_t can manage.  Then
>>> figure out what access is required to mount.
>>
>> Good point.  We should probably reconsider the setfiles usage from
>> webadm too.
> 
> The attached patch is a revised one.
> - seutil_domtrans_setfiles() was removed
> - staff_role_change_to() was removed, and I put dbadm_role_change()
>    on the staff.te
> - Fix an obvious typo.
> 
> It is not clear for me whether the idea to allow relabelfrom/relabelto
> for all the files dbadm_t can manage, because it is eventually necessary
> someone to relabel (or assign initial labels) files from unlabeled one
> to managed labels when we mount a new disk.
> 
> If so, should it be a task of sysadm_t to mount new disk and assign
> security context correctly, instead of webadm_t/dbadm_t?
> 
> Thanks,
> 
> 
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy


-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-dbadm-revise.3.patch
Type: text/x-patch
Size: 2409 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100816/cd4a84e8/attachment-0001.bin 

[refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)

[Christopher J. PeBenito]

On 08/16/10 05:11, KaiGai Kohei wrote:
> Sorry for this long silent on the topic.
>
> IIRC, we have already agreed most part of the patch, haven't we?
>
> - The dbadm_t domain shall be launched via sudo, not a login shell,
>    so, userdom_base_user_template() is used to grant basic privileges
>    to dbadm_t instead of userdom_unpriv_user_template().
> - It allows too much privileges to dbadm_t, if we allows him to launch
>    setfiles, so we removed seutil_domtrans_setfiles().
>
> Did we have any more issues?
>
> The attached patch is same as the last version except for it was rebased
> to the latest reference policy.

I only have two issues:

1. Why should dbadm be allowed to set enforce mode?
2. Why does dbadm need to manage generic locks?

After those are resolved, it can be merged.

> (2010/04/15 15:02), KaiGai Kohei wrote:
>> (2010/04/14 0:57), Christopher J. PeBenito wrote:
>>> On Tue, 2010-04-13 at 11:15 -0400, Daniel J Walsh wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 04/13/2010 09:17 AM, Christopher J. PeBenito wrote:
>>>>> On Tue, 2010-04-13 at 09:28 +0900, KaiGai Kohei wrote:
>>>>>> (2010/04/12 23:09), Christopher J. PeBenito wrote:
>>>>>>> On Fri, 2010-04-09 at 14:29 +0900, KaiGai Kohei wrote:
>>>>>>>> (2010/04/08 21:15), Daniel J Walsh wrote:
>>>>>>>>> As Dominick stated.  I prefer to think in terms of two different roles.
>>>>>>>>>       Login Roles, and Roles to execute in when you have privileges (IE Root).
>>>>>>>>>
>>>>>>>>> Login Roles/Types
>>>>>>>>> staff_t, user_t, unconfined_t, xguest_t, guest_t
>>>>>>>>>
>>>>>>>>> Three interfaces can be used to create confined login users.
>>>>>>>>>
>>>>>>>>> userdom_restricted_user_template(guest)
>>>>>>>>> userdom_restricted_xwindows_user_template(xguest)
>>>>>>>>> userdom_unpriv_user_template(staff)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Admin Roles/Types
>>>>>>>>> logadm_t, webadm_t, secadm_t, auditadm_t
>>>>>>>>>
>>>>>>>>> The following interface can be used to create an Admin ROle
>>>>>>>>> userdom_base_user_template(logadm)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> sysadm_t is sort of a hybrid, most people use it as an Admin Role.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I imagine that you login as a confined user and then use sudo/newrole to
>>>>>>>>> switch roles to one of the admin roles.
>>>>>>>>
>>>>>>>> The attached patch revises roles/dbadm.te (to be applied on the upstream
>>>>>>>> reference policy). It uses userdom_base_user_template() instead of the
>>>>>>>> userdom_unpriv_user_template(), and should be launched via sudo/newrole.
>>>>>>>> In the default, it intends the dbadm_r role to be launched by staff_r role.
>>>>>>>
>>>>>>> Why does dbadm need to run setfiles?
>>>>>>
>>>>>> The database files (typically, /var/lib/(se)?pgsql/*) have to be labeled
>>>>>> correctly, so I thought dbadm needs to run setfiles.
>>>>>> However, as long as they initialize database files using init script,
>>>>>> initrc_t domain performs this initial labeling, so it might not be necessary.
>>>>>>
>>>>>> On the other hand, PostgreSQL support a feature to use multiple disks
>>>>>> within a single database instance for performance utilization.
>>>>>> (Called TABLESPACE; I don't know whether MySQL has such a feature.)
>>>>>>
>>>>>> http://archives.postgresql.org/pgsql-general/2006-08/msg00142.php
>>>>>>
>>>>>> It requires administrators to assign proper security context on the secondary
>>>>>> directory, or to mount the secondary disk with context='...' option.
>>>>>>
>>>>>> Is there any good idea?
>>>>>>
>>>>>> Or, it should not be a task for dbadm?
>>>>>
>>>>> Ok, the transition for setfiles is fine.
>>>>>
>>>>
>>>> I would be carefull with this.  Since setfiles can take a parameter of a
>>>> file context file.  I think it would be better to only give
>>>> relabefrom/relabelto privs for all labels dbadm_t can manage.  Then
>>>> figure out what access is required to mount.
>>>
>>> Good point.  We should probably reconsider the setfiles usage from
>>> webadm too.
>>
>> The attached patch is a revised one.
>> - seutil_domtrans_setfiles() was removed
>> - staff_role_change_to() was removed, and I put dbadm_role_change()
>>     on the staff.te
>> - Fix an obvious typo.
>>
>> It is not clear for me whether the idea to allow relabelfrom/relabelto
>> for all the files dbadm_t can manage, because it is eventually necessary
>> someone to relabel (or assign initial labels) files from unlabeled one
>> to managed labels when we mount a new disk.
>>
>> If so, should it be a task of sysadm_t to mount new disk and assign
>> security context correctly, instead of webadm_t/dbadm_t?
>>
>> Thanks,

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)

[KaiGai Kohei]

(2010/08/17 4:42), Christopher J. PeBenito wrote:
> On 08/16/10 05:11, KaiGai Kohei wrote:
>> Sorry for this long silent on the topic.
>>
>> IIRC, we have already agreed most part of the patch, haven't we?
>>
>> - The dbadm_t domain shall be launched via sudo, not a login shell,
>> so, userdom_base_user_template() is used to grant basic privileges
>> to dbadm_t instead of userdom_unpriv_user_template().
>> - It allows too much privileges to dbadm_t, if we allows him to launch
>> setfiles, so we removed seutil_domtrans_setfiles().
>>
>> Did we have any more issues?
>>
>> The attached patch is same as the last version except for it was rebased
>> to the latest reference policy.
> 
> I only have two issues:
> 
> 1. Why should dbadm be allowed to set enforce mode?

It uses selinux_get_enforce_mode(), not selinux_set_enforce_mode().
We just allow dbadm_t to see the current working mode.

> 2. Why does dbadm need to manage generic locks?

It was originally copied from webadb.te, but PostgreSQL also makes
its lockfile on the /var/lock/subsys/postgresql. If server process
unexpectedly crashed, dbadm_t need to remove it by hand, doesn't it?

Thanks,

> After those are resolved, it can be merged.
> 
>> (2010/04/15 15:02), KaiGai Kohei wrote:
>>> (2010/04/14 0:57), Christopher J. PeBenito wrote:
>>>> On Tue, 2010-04-13 at 11:15 -0400, Daniel J Walsh wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> On 04/13/2010 09:17 AM, Christopher J. PeBenito wrote:
>>>>>> On Tue, 2010-04-13 at 09:28 +0900, KaiGai Kohei wrote:
>>>>>>> (2010/04/12 23:09), Christopher J. PeBenito wrote:
>>>>>>>> On Fri, 2010-04-09 at 14:29 +0900, KaiGai Kohei wrote:
>>>>>>>>> (2010/04/08 21:15), Daniel J Walsh wrote:
>>>>>>>>>> As Dominick stated. I prefer to think in terms of two 
>>>>>>>>>> different roles.
>>>>>>>>>> Login Roles, and Roles to execute in when you have privileges 
>>>>>>>>>> (IE Root).
>>>>>>>>>>
>>>>>>>>>> Login Roles/Types
>>>>>>>>>> staff_t, user_t, unconfined_t, xguest_t, guest_t
>>>>>>>>>>
>>>>>>>>>> Three interfaces can be used to create confined login users.
>>>>>>>>>>
>>>>>>>>>> userdom_restricted_user_template(guest)
>>>>>>>>>> userdom_restricted_xwindows_user_template(xguest)
>>>>>>>>>> userdom_unpriv_user_template(staff)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Admin Roles/Types
>>>>>>>>>> logadm_t, webadm_t, secadm_t, auditadm_t
>>>>>>>>>>
>>>>>>>>>> The following interface can be used to create an Admin ROle
>>>>>>>>>> userdom_base_user_template(logadm)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> sysadm_t is sort of a hybrid, most people use it as an Admin 
>>>>>>>>>> Role.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I imagine that you login as a confined user and then use 
>>>>>>>>>> sudo/newrole to
>>>>>>>>>> switch roles to one of the admin roles.
>>>>>>>>>
>>>>>>>>> The attached patch revises roles/dbadm.te (to be applied on the 
>>>>>>>>> upstream
>>>>>>>>> reference policy). It uses userdom_base_user_template() instead 
>>>>>>>>> of the
>>>>>>>>> userdom_unpriv_user_template(), and should be launched via 
>>>>>>>>> sudo/newrole.
>>>>>>>>> In the default, it intends the dbadm_r role to be launched by 
>>>>>>>>> staff_r role.
>>>>>>>>
>>>>>>>> Why does dbadm need to run setfiles?
>>>>>>>
>>>>>>> The database files (typically, /var/lib/(se)?pgsql/*) have to be 
>>>>>>> labeled
>>>>>>> correctly, so I thought dbadm needs to run setfiles.
>>>>>>> However, as long as they initialize database files using init 
>>>>>>> script,
>>>>>>> initrc_t domain performs this initial labeling, so it might not 
>>>>>>> be necessary.
>>>>>>>
>>>>>>> On the other hand, PostgreSQL support a feature to use multiple 
>>>>>>> disks
>>>>>>> within a single database instance for performance utilization.
>>>>>>> (Called TABLESPACE; I don't know whether MySQL has such a feature.)
>>>>>>>
>>>>>>> http://archives.postgresql.org/pgsql-general/2006-08/msg00142.php
>>>>>>>
>>>>>>> It requires administrators to assign proper security context on 
>>>>>>> the secondary
>>>>>>> directory, or to mount the secondary disk with context='...' option.
>>>>>>>
>>>>>>> Is there any good idea?
>>>>>>>
>>>>>>> Or, it should not be a task for dbadm?
>>>>>>
>>>>>> Ok, the transition for setfiles is fine.
>>>>>>
>>>>>
>>>>> I would be carefull with this. Since setfiles can take a parameter 
>>>>> of a
>>>>> file context file. I think it would be better to only give
>>>>> relabefrom/relabelto privs for all labels dbadm_t can manage. Then
>>>>> figure out what access is required to mount.
>>>>
>>>> Good point. We should probably reconsider the setfiles usage from
>>>> webadm too.
>>>
>>> The attached patch is a revised one.
>>> - seutil_domtrans_setfiles() was removed
>>> - staff_role_change_to() was removed, and I put dbadm_role_change()
>>> on the staff.te
>>> - Fix an obvious typo.
>>>
>>> It is not clear for me whether the idea to allow relabelfrom/relabelto
>>> for all the files dbadm_t can manage, because it is eventually necessary
>>> someone to relabel (or assign initial labels) files from unlabeled one
>>> to managed labels when we mount a new disk.
>>>
>>> If so, should it be a task of sysadm_t to mount new disk and assign
>>> security context correctly, instead of webadm_t/dbadm_t?
>>>
>>> Thanks,
> 


-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>

[refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)

[Chris PeBenito]

On 08/16/10 19:37, KaiGai Kohei wrote:
> (2010/08/17 4:42), Christopher J. PeBenito wrote:
>> On 08/16/10 05:11, KaiGai Kohei wrote:
>>> Sorry for this long silent on the topic.
>>>
>>> IIRC, we have already agreed most part of the patch, haven't we?
>>>
>>> - The dbadm_t domain shall be launched via sudo, not a login shell,
>>> so, userdom_base_user_template() is used to grant basic privileges
>>> to dbadm_t instead of userdom_unpriv_user_template().
>>> - It allows too much privileges to dbadm_t, if we allows him to launch
>>> setfiles, so we removed seutil_domtrans_setfiles().
>>>
>>> Did we have any more issues?
>>>
>>> The attached patch is same as the last version except for it was rebased
>>> to the latest reference policy.
>>
>> I only have two issues:
>>
>> 1. Why should dbadm be allowed to set enforce mode?
>
> It uses selinux_get_enforce_mode(), not selinux_set_enforce_mode().
> We just allow dbadm_t to see the current working mode.

My mistake, I misread it.  You're right, its fine.

>> 2. Why does dbadm need to manage generic locks?
>
> It was originally copied from webadb.te, but PostgreSQL also makes
> its lockfile on the /var/lock/subsys/postgresql. If server process
> unexpectedly crashed, dbadm_t need to remove it by hand, doesn't it?

Based on what I see in the policy, my guess is this file is created by 
the init script, right?  If not, then it sounds like PostgreSQL needs a 
lock type.

I'd rather it just have delete permissions, rather than full manage 
permissions.  Something like files_delete_all_locks(), but for 
var_lock_t instead.

> Thanks,
>
>> After those are resolved, it can be merged.

[refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)

[KaiGai Kohei]

(2010/08/18 3:00), Chris PeBenito wrote:
> On 08/16/10 19:37, KaiGai Kohei wrote:
>> (2010/08/17 4:42), Christopher J. PeBenito wrote:
>>> On 08/16/10 05:11, KaiGai Kohei wrote:
>>>> Sorry for this long silent on the topic.
>>>>
>>>> IIRC, we have already agreed most part of the patch, haven't we?
>>>>
>>>> - The dbadm_t domain shall be launched via sudo, not a login shell,
>>>> so, userdom_base_user_template() is used to grant basic privileges
>>>> to dbadm_t instead of userdom_unpriv_user_template().
>>>> - It allows too much privileges to dbadm_t, if we allows him to launch
>>>> setfiles, so we removed seutil_domtrans_setfiles().
>>>>
>>>> Did we have any more issues?
>>>>
>>>> The attached patch is same as the last version except for it was 
>>>> rebased
>>>> to the latest reference policy.
>>>
>>> I only have two issues:
>>>
>>> 1. Why should dbadm be allowed to set enforce mode?
>>
>> It uses selinux_get_enforce_mode(), not selinux_set_enforce_mode().
>> We just allow dbadm_t to see the current working mode.
> 
> My mistake, I misread it. You're right, its fine.
> 
>>> 2. Why does dbadm need to manage generic locks?
>>
>> It was originally copied from webadb.te, but PostgreSQL also makes
>> its lockfile on the /var/lock/subsys/postgresql. If server process
>> unexpectedly crashed, dbadm_t need to remove it by hand, doesn't it?
> 
> Based on what I see in the policy, my guess is this file is created by 
> the init script, right? If not, then it sounds like PostgreSQL needs a 
> lock type.
> 
Yes, this file is created by the init script.

In addition, postgresql_lock_t is defined, but type_transition rule is
defined on a pair of postgresql_t and var_lock_t, so the lockfile shall
be labeled as var_lock_t.

  [root at saba ~]# ls -Z /var/lock/subsys/postgresql
  -rw-r--r--. root root dbadm_u:object_r:var_lock_t:s0   /var/lock/subsys/postgresql

Maybe, init script should relabel it to postgresql_lock_t, ideally?

> I'd rather it just have delete permissions, rather than full manage 
> permissions. Something like files_delete_all_locks(), but for var_lock_t 
> instead.
> 
I tried to define files_delete_generic_locks(), instead of the manage.

Thanks,
-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-dbadm-revise.4.patch
Type: text/x-patch
Size: 3441 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100818/1de3086e/attachment.bin 

[refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)

[Christopher J. PeBenito]

On 08/18/10 04:19, KaiGai Kohei wrote:
> (2010/08/18 3:00), Chris PeBenito wrote:
>> On 08/16/10 19:37, KaiGai Kohei wrote:
>>> (2010/08/17 4:42), Christopher J. PeBenito wrote:
>>>> On 08/16/10 05:11, KaiGai Kohei wrote:
>>>>> Sorry for this long silent on the topic.
>>>>>
>>>>> IIRC, we have already agreed most part of the patch, haven't we?
>>>>>
>>>>> - The dbadm_t domain shall be launched via sudo, not a login shell,
>>>>> so, userdom_base_user_template() is used to grant basic privileges
>>>>> to dbadm_t instead of userdom_unpriv_user_template().
>>>>> - It allows too much privileges to dbadm_t, if we allows him to launch
>>>>> setfiles, so we removed seutil_domtrans_setfiles().
>>>>>
>>>>> Did we have any more issues?
>>>>>
>>>>> The attached patch is same as the last version except for it was
>>>>> rebased
>>>>> to the latest reference policy.
>>>>
>>>> I only have two issues:
>>>>
>>>> 1. Why should dbadm be allowed to set enforce mode?
>>>
>>> It uses selinux_get_enforce_mode(), not selinux_set_enforce_mode().
>>> We just allow dbadm_t to see the current working mode.
>>
>> My mistake, I misread it. You're right, its fine.
>>
>>>> 2. Why does dbadm need to manage generic locks?
>>>
>>> It was originally copied from webadb.te, but PostgreSQL also makes
>>> its lockfile on the /var/lock/subsys/postgresql. If server process
>>> unexpectedly crashed, dbadm_t need to remove it by hand, doesn't it?
>>
>> Based on what I see in the policy, my guess is this file is created by
>> the init script, right? If not, then it sounds like PostgreSQL needs a
>> lock type.
>>
> Yes, this file is created by the init script.
>
> In addition, postgresql_lock_t is defined, but type_transition rule is
> defined on a pair of postgresql_t and var_lock_t, so the lockfile shall
> be labeled as var_lock_t.
>
>    [root at saba ~]# ls -Z /var/lock/subsys/postgresql
>    -rw-r--r--. root root dbadm_u:object_r:var_lock_t:s0   /var/lock/subsys/postgresql
>
> Maybe, init script should relabel it to postgresql_lock_t, ideally?

It might be nice to do this for all services, but since it requires 
script changes, its not likely to happen.  So theres probably no point 
in doing this for just a couple services.

As it is, I think its more of a lock for the init script system, so if 
anything we should probably think about making these locks made by the 
init scripts have a initrc_lock_t type.

>> I'd rather it just have delete permissions, rather than full manage
>> permissions. Something like files_delete_all_locks(), but for var_lock_t
>> instead.
>>
> I tried to define files_delete_generic_locks(), instead of the manage.

Merged, with one minor change -- I moved the declaration of the above 
interface.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com