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

-----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

Quoted 26 lines · Daniel J Walsh

-----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.

Quoted 2 lines

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.

Quoted 30 lines · KaiGai Kohei

Quoted 28 lines · Daniel J Walsh

-----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.

Quoted 4 lines

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.

Quoted 28 lines · Christopher J. PeBenito

Quoted 27 lines · KaiGai Kohei

Quoted 25 lines · Daniel J Walsh

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.

Quoted 6 lines

Quoted 4 lines

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?

Quoted 47 lines · KaiGai Kohei

Quoted 28 lines · Christopher J. PeBenito

Quoted 27 lines · KaiGai Kohei

Quoted 25 lines · Daniel J Walsh

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.

Quoted 6 lines

Quoted 4 lines

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

Quoted 6 lines

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.

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

Quoted 55 lines · Christopher J. PeBenito

Quoted 53 lines · KaiGai Kohei

Quoted 28 lines · Christopher J. PeBenito

Quoted 27 lines · KaiGai Kohei

Quoted 25 lines · Daniel J Walsh

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.

Quoted 6 lines

Quoted 4 lines

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?

Quoted 2 lines

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.

Quoted 62 lines · Daniel J Walsh

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

Quoted 57 lines · Christopher J. PeBenito

Quoted 45 lines · KaiGai Kohei

Quoted 28 lines · Christopher J. PeBenito

Quoted 27 lines · KaiGai Kohei

Quoted 25 lines · Daniel J Walsh

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.

Quoted 6 lines

Quoted 4 lines

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.)

Quoted 8 lines

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.

Quoted 4 lines

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.

Quoted 63 lines · Christopher J. PeBenito

Quoted 62 lines · Daniel J Walsh

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

Quoted 57 lines · Christopher J. PeBenito

Quoted 45 lines · KaiGai Kohei

Quoted 28 lines · Christopher J. PeBenito

Quoted 27 lines · KaiGai Kohei

Quoted 25 lines · Daniel J Walsh

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.

Quoted 6 lines

Quoted 4 lines

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.)

Quoted 8 lines

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.

Quoted 7 lines

Quoted 4 lines

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,

--
selinux mailing list
selinux at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

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

Quoted 78 lines · KaiGai Kohei

Quoted 63 lines · Christopher J. PeBenito

Quoted 62 lines · Daniel J Walsh

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

Quoted 57 lines · Christopher J. PeBenito

Quoted 45 lines · KaiGai Kohei

Quoted 28 lines · Christopher J. PeBenito

Quoted 27 lines · KaiGai Kohei

Quoted 25 lines · Daniel J Walsh

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.

Quoted 6 lines

Quoted 4 lines

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.)

Quoted 8 lines

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.

Quoted 7 lines

Quoted 4 lines

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.

Quoted 8 lines

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.

Quoted 63 lines · Christopher J. PeBenito

Quoted 62 lines · Daniel J Walsh

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

Quoted 57 lines · Christopher J. PeBenito

Quoted 45 lines · KaiGai Kohei

Quoted 28 lines · Christopher J. PeBenito

Quoted 27 lines · KaiGai Kohei

Quoted 25 lines · Daniel J Walsh

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.

Quoted 6 lines

Quoted 4 lines

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.)

Quoted 8 lines

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.

Quoted 7 lines

Quoted 4 lines

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

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.

Quoted 87 lines · KaiGai Kohei

Quoted 63 lines · Christopher J. PeBenito

Quoted 62 lines · Daniel J Walsh

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

Quoted 57 lines · Christopher J. PeBenito

Quoted 45 lines · KaiGai Kohei

Quoted 28 lines · Christopher J. PeBenito

Quoted 27 lines · KaiGai Kohei

Quoted 25 lines · Daniel J Walsh

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.

Quoted 6 lines

Quoted 4 lines

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.)

Quoted 8 lines

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.

Quoted 7 lines

Quoted 4 lines

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,

Quoted 10 lines · 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().

Quoted 4 lines

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.

Quoted 102 lines

Quoted 101 lines · KaiGai Kohei

Quoted 76 lines · Christopher J. PeBenito

Quoted 75 lines · Daniel J Walsh

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

Quoted 70 lines · Christopher J. PeBenito

Quoted 59 lines · KaiGai Kohei

Quoted 41 lines · Christopher J. PeBenito

Quoted 31 lines · KaiGai Kohei

Quoted 22 lines · Daniel J Walsh

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)

Quoted 7 lines

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.

Quoted 8 lines

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.

Quoted 1 line

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

Quoted 7 lines

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.

Quoted 8 lines

Quoted 5 lines

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,

Quoted 16 lines · Christopher J. PeBenito

Quoted 14 lines · 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.

Quoted 3 lines

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.

Quoted 1 line

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,

Quoted 1 line

After those are resolved, it can be merged.

Quoted 18 lines · KaiGai Kohei

Quoted 17 lines · Christopher J. PeBenito

Quoted 15 lines · 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.

Quoted 6 lines

Quoted 3 lines

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.

Quoted 2 lines

Quoted 1 line

2. Why does dbadm need to manage generic locks?

Quoted 3 lines

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.

Quoted 30 lines · Chris PeBenito

Quoted 18 lines · KaiGai Kohei

Quoted 17 lines · Christopher J. PeBenito

Quoted 15 lines · 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.

Quoted 6 lines

Quoted 3 lines

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.

Quoted 2 lines

Quoted 1 line

2. Why does dbadm need to manage generic locks?

Quoted 8 lines

Quoted 3 lines

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?

Quoted 4 lines

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.

-----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

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.

Quoted 31 lines · Daniel J Walsh

-----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.