(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,
-----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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
(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,
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@oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy
selinux@lists.fedoraproject.org