(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 <[email protected]>
-------------- 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
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
(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 <[email protected]>
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
-----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-----
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
(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 <[email protected]>
-------------- 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
-----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-----
(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 <[email protected]>
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 <[email protected]>
-------------- 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
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
http://www.tresys.com | oss.tresys.com
(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 <[email protected]>
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.
(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 <[email protected]>
-------------- 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
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
http://www.tresys.com | oss.tresys.com