Hi everybody,
I have seen this topic pop up on this ML previously but without much traction. However I'll try it again ;)
I'm building PostgreSQL setup with PGPool-II replication and PITR. After some tinkering I've arrived at a module with contents:
===pgsql-pitr.te===
module pgsql-pitr 1.7;
require { type ssh_home_t; type ssh_port_t; type ssh_exec_t; type rsync_exec_t; type postgresql_t; class tcp_socket name_connect; class file { getattr execute read open execute_no_trans }; class dir { search getattr }; }
allow postgresql_t rsync_exec_t:file { read open execute_no_trans getattr execute };
allow postgresql_t ssh_exec_t:file { read open execute execute_no_trans };
allow postgresql_t ssh_home_t:dir { search getattr }; allow postgresql_t ssh_home_t:file { read open getattr };
allow postgresql_t ssh_port_t:tcp_socket name_connect;
===end of pgsql-pitr.te===
All of the above to allow me to launch rsync as an "archive_command" from postgres an copy WAL files from primary over to secondary, generated from auditd messages thus very specific. I could probably drop the rsync part and go with scp alone but that won't change what I'm about to ask.
What I really wander about is - above I've opened up quite a few things that are very specific to this mode of operation, however I can't believe I'm in a situation nobody else have been before and there are no booleans/tunables for most of things outlined above. So is there a way to make above utilize existing hooks or is it "as good as it gets"?
On Tue, 2012-09-18 at 13:32 -0600, Dmitry Makovey wrote:
What I really wander about is - above I've opened up quite a few things that are very specific to this mode of operation, however I can't believe I'm in a situation nobody else have been before and there are no booleans/tunables for most of things outlined above. So is there a way to make above utilize existing hooks or is it "as good as it gets"?
Hi
This actually looks pretty good in this case and well suited for a boolean in the postgresql policy in my opinion.
Currently this is indeed not supported by the policy it seems.
Why not file a bugzilla report as a feature request?
Hi Dominick,
thanks for your reply, see responses below:
On September 18, 2012 22:31:02 Dominick Grift wrote:
On Tue, 2012-09-18 at 13:32 -0600, Dmitry Makovey wrote:
What I really wander about is - above I've opened up quite a few things that are very specific to this mode of operation, however I can't believe I'm in a situation nobody else have been before and there are no booleans/tunables for most of things outlined above. So is there a way to make above utilize existing hooks or is it "as good as it gets"?
Hi
This actually looks pretty good in this case and well suited for a boolean in the postgresql policy in my opinion.
good to know it's not just me who thinks that way :)
Currently this is indeed not supported by the policy it seems.
Why not file a bugzilla report as a feature request?
https://bugzilla.redhat.com/show_bug.cgi?id=858406
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/18/2012 06:03 PM, Dmitry Makovey wrote:
Hi Dominick,
thanks for your reply, see responses below:
On September 18, 2012 22:31:02 Dominick Grift wrote:
On Tue, 2012-09-18 at 13:32 -0600, Dmitry Makovey wrote:
What I really wander about is - above I've opened up quite a few things that are very specific to this mode of operation, however I can't believe I'm in a situation nobody else have been before and there are no booleans/tunables for most of things outlined above. So is there a way to make above utilize existing hooks or is it "as good as it gets"?
Hi
This actually looks pretty good in this case and well suited for a boolean in the postgresql policy in my opinion.
good to know it's not just me who thinks that way :)
Currently this is indeed not supported by the policy it seems.
Why not file a bugzilla report as a feature request?
How about something like this?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/18/2012 06:03 PM, Dmitry Makovey wrote:
Hi Dominick,
thanks for your reply, see responses below:
On September 18, 2012 22:31:02 Dominick Grift wrote:
On Tue, 2012-09-18 at 13:32 -0600, Dmitry Makovey wrote:
What I really wander about is - above I've opened up quite a few things that are very specific to this mode of operation, however I can't believe I'm in a situation nobody else have been before and there are no booleans/tunables for most of things outlined above. So is there a way to make above utilize existing hooks or is it "as good as it gets"?
Hi
This actually looks pretty good in this case and well suited for a boolean in the postgresql policy in my opinion.
good to know it's not just me who thinks that way :)
Currently this is indeed not supported by the policy it seems.
Why not file a bugzilla report as a feature request?
How about this?
On Wed, 2012-09-19 at 15:07 -0400, Daniel J Walsh wrote:
## <desc> ## <p> +## Allow postgresql to use ssh and rsync to replicate databases +## </p> +## </desc> +gen_tunable(postgesql_replication, false)
typo in there
we should probably implement a ssh_tcp_connect if it doesnt exists already and use that (that goes for all service ports)
######################################## ## <summary> ## Connect to ssh over the TCP network. ## </summary> ## <param name="domain"> ## <summary> ## Domain allowed access. ## </summary> ## </param> # interface(`ssh_tcp_connect',` gen_require(` type sshd_t; ')
corenet_tcp_recvfrom_labeled($1, sshd_t) corenet_tcp_sendrecv_ssh_port($1) corenet_tcp_connect_ssh_port($1) corenet_sendrecv_ssh_client_packets($1) ')
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/19/2012 03:20 PM, Dominick Grift wrote:
On Wed, 2012-09-19 at 15:07 -0400, Daniel J Walsh wrote:
## <desc> ## <p> +## Allow postgresql to use ssh and rsync to replicate databases +## </p> +## </desc> +gen_tunable(postgesql_replication, false)
typo in there
we should probably implement a ssh_tcp_connect if it doesnt exists already and use that (that goes for all service ports)
######################################## ## <summary> ## Connect to ssh over the TCP network. ## </summary> ## <param name="domain"> ## <summary> ## Domain allowed access. ## </summary> ## </param> # interface(`ssh_tcp_connect',` gen_require(` type sshd_t; ')
corenet_tcp_recvfrom_labeled($1, sshd_t) corenet_tcp_sendrecv_ssh_port($1) corenet_tcp_connect_ssh_port($1) corenet_sendrecv_ssh_client_packets($1) ')
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Sure that is fine with me.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/19/2012 03:20 PM, Dominick Grift wrote:
On Wed, 2012-09-19 at 15:07 -0400, Daniel J Walsh wrote:
## <desc> ## <p> +## Allow postgresql to use ssh and rsync to replicate databases +## </p> +## </desc> +gen_tunable(postgesql_replication, false)
typo in there
we should probably implement a ssh_tcp_connect if it doesnt exists already and use that (that goes for all service ports)
######################################## ## <summary> ## Connect to ssh over the TCP network. ## </summary> ## <param name="domain"> ## <summary> ## Domain allowed access. ## </summary> ## </param> # interface(`ssh_tcp_connect',` gen_require(` type sshd_t; ')
corenet_tcp_recvfrom_labeled($1, sshd_t) corenet_tcp_sendrecv_ssh_port($1) corenet_tcp_connect_ssh_port($1) corenet_sendrecv_ssh_client_packets($1) ')
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Looks like Chris did not like a previous interface by that name. ######################################## ## <summary> ## Connect to SSH daemons over TCP sockets. (Deprecated) ## </summary> ## <param name="domain"> ## <summary> ## Domain allowed access. ## </summary> ## </param> # interface(`ssh_tcp_connect',` refpolicywarn(`$0($*) has been deprecated.') ')
On Wed, 2012-09-19 at 16:01 -0400, Daniel J Walsh wrote:
On 09/19/2012 03:20 PM, Dominick Grift wrote:
On Wed, 2012-09-19 at 15:07 -0400, Daniel J Walsh wrote:
## <desc> ## <p> +## Allow postgresql to use ssh and rsync to replicate databases +## </p> +## </desc> +gen_tunable(postgesql_replication, false)
typo in there
we should probably implement a ssh_tcp_connect if it doesnt exists already and use that (that goes for all service ports)
######################################## ## <summary> ## Connect to ssh over the TCP network. ## </summary> ## <param name="domain"> ## <summary> ## Domain allowed access. ## </summary> ## </param> # interface(`ssh_tcp_connect',` gen_require(` type sshd_t; ')
corenet_tcp_recvfrom_labeled($1, sshd_t) corenet_tcp_sendrecv_ssh_port($1) corenet_tcp_connect_ssh_port($1) corenet_sendrecv_ssh_client_packets($1) ')
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Looks like Chris did not like a previous interface by that name. ######################################## ## <summary> ## Connect to SSH daemons over TCP sockets. (Deprecated) ## </summary> ## <param name="domain"> ## <summary> ## Domain allowed access. ## </summary> ## </param> # interface(`ssh_tcp_connect',` refpolicywarn(`$0($*) has been deprecated.') ')
I noticed that and i dont know why. Its also inconsistent because mysql and postgres have it but some have it deprecated like i guess ssh and snmp
I actually like this interface it provides support for labeled networking.
On Wed, 2012-09-19 at 16:01 -0400, Daniel J Walsh wrote:
On 09/19/2012 03:20 PM, Dominick Grift wrote:
On Wed, 2012-09-19 at 15:07 -0400, Daniel J Walsh wrote:
## <desc> ## <p> +## Allow postgresql to use ssh and rsync to replicate databases +## </p> +## </desc> +gen_tunable(postgesql_replication, false)
typo in there
we should probably implement a ssh_tcp_connect if it doesnt exists already and use that (that goes for all service ports)
######################################## ## <summary> ## Connect to ssh over the TCP network. ## </summary> ## <param name="domain"> ## <summary> ## Domain allowed access. ## </summary> ## </param> # interface(`ssh_tcp_connect',` gen_require(` type sshd_t; ')
corenet_tcp_recvfrom_labeled($1, sshd_t) corenet_tcp_sendrecv_ssh_port($1) corenet_tcp_connect_ssh_port($1) corenet_sendrecv_ssh_client_packets($1) ')
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Looks like Chris did not like a previous interface by that name. ######################################## ## <summary> ## Connect to SSH daemons over TCP sockets. (Deprecated) ## </summary> ## <param name="domain"> ## <summary> ## Domain allowed access. ## </summary> ## </param> # interface(`ssh_tcp_connect',` refpolicywarn(`$0($*) has been deprecated.') ')
Anyways , ok ignore it for now. I guess this should be discussed with pebenito. I can always change it later
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/19/2012 03:44 PM, Dominick Grift wrote:
On Wed, 2012-09-19 at 15:07 -0400, Daniel J Walsh wrote:
How about this?
maybe postgresql_pitr is a more suitable boolean name. not sure about that but just seems that way to me.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Sure although I had no idea what PITR was until I asked google.
On September 19, 2012 15:53:10 Daniel J Walsh wrote:
Sure although I had no idea what PITR was until I asked google.
if I may suggest in tune with some other tunables (no pun intended)
postgres_can_rsync ?
PITR, while implemented in most cases just about the same as I outlined is more of a concept and could be implemented using alternative strategies (say, no SSH involved and dumping directly to NFS share), thus mentioning specific ability "rsync" may be more descriptive.
Just my .02CDN on the subject...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/19/2012 04:10 PM, Dmitry Makovey wrote:
On September 19, 2012 15:53:10 Daniel J Walsh wrote:
Sure although I had no idea what PITR was until I asked google.
if I may suggest in tune with some other tunables (no pun intended)
postgres_can_rsync ?
PITR, while implemented in most cases just about the same as I outlined is more of a concept and could be implemented using alternative strategies (say, no SSH involved and dumping directly to NFS share), thus mentioning specific ability "rsync" may be more descriptive.
Just my .02CDN on the subject...
I am fine with that also. Will Let Dominick be the final arbiter.
On Wed, 2012-09-19 at 14:10 -0600, Dmitry Makovey wrote:
On September 19, 2012 15:53:10 Daniel J Walsh wrote:
Sure although I had no idea what PITR was until I asked google.
if I may suggest in tune with some other tunables (no pun intended)
postgres_can_rsync ?
PITR, while implemented in most cases just about the same as I outlined is more of a concept and could be implemented using alternative strategies (say, no SSH involved and dumping directly to NFS share), thus mentioning specific ability "rsync" may be more descriptive.
Just my .02CDN on the subject...
Thanks, good point
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/19/2012 04:19 PM, Dominick Grift wrote:
On Wed, 2012-09-19 at 14:10 -0600, Dmitry Makovey wrote:
On September 19, 2012 15:53:10 Daniel J Walsh wrote:
Sure although I had no idea what PITR was until I asked google.
if I may suggest in tune with some other tunables (no pun intended)
postgres_can_rsync ?
PITR, while implemented in most cases just about the same as I outlined is more of a concept and could be implemented using alternative strategies (say, no SSH involved and dumping directly to NFS share), thus mentioning specific ability "rsync" may be more descriptive.
Just my .02CDN on the subject...
Thanks, good point
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Sadly it looks like we already have a boolean for this in Fedora fro sepostgresql.
optional_policy(` tunable_policy(`sepgsql_enable_pitr_implementation',` corenet_tcp_connect_ssh_port(postgresql_t) rsync_exec(postgresql_t) ssh_read_user_home_files(postgresql_t) ssh_exec(postgresql_t) ') ')
Since this has nothing specific to do with sepgsql, we can change the name of the boolean.
On September 19, 2012 16:22:12 Daniel J Walsh wrote:
Sadly it looks like we already have a boolean for this in Fedora fro sepostgresql.
optional_policy(` tunable_policy(`sepgsql_enable_pitr_implementation',` corenet_tcp_connect_ssh_port(postgresql_t) rsync_exec(postgresql_t) ssh_read_user_home_files(postgresql_t) ssh_exec(postgresql_t) ') ')
Since this has nothing specific to do with sepgsql, we can change the name of the boolean.
Daniel, you saved my day - I thought that something like that should exist but I completely ommited sepgsql* set as I was under impression that it applied to a completely different functionality. I'll use that instead of my module. Thank you very much.
For what it's worth I'd like to second the name change as existing one put me off-track, like many other people (just look up "postgres selinux rsync").
On September 19, 2012 15:20:17 Dmitry Makovey wrote:
Daniel, you saved my day - I thought that something like that should exist but I completely ommited sepgsql* set as I was under impression that it applied to a completely different functionality. I'll use that instead of my module. Thank you very much.
spoke too soon:
# setsebool sepgsql_enable_pitr_implementation On Could not change active booleans: Invalid boolean
so it sounds like it doesn't exist in RHEL? yet?
On September 19, 2012 15:27:43 Dmitry Makovey wrote:
On September 19, 2012 15:20:17 Dmitry Makovey wrote:
Daniel, you saved my day - I thought that something like that should exist but I completely ommited sepgsql* set as I was under impression that it applied to a completely different functionality. I'll use that instead of my module. Thank you very much.
spoke too soon:
# setsebool sepgsql_enable_pitr_implementation On Could not change active booleans: Invalid boolean
so it sounds like it doesn't exist in RHEL? yet?
ok as per https://bugzilla.redhat.com/show_bug.cgi?id=858406 , Miroslav just added it, so it definitely doesn't exist yet. But it sounds like it is on it's way.. thank you Dan and Dominick for the help. I'll stick with my module for now.
What's the best way of tracking whether above changes made it into RHEL6 policies? Just the changelog?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/19/2012 05:35 PM, Dmitry Makovey wrote:
On September 19, 2012 15:27:43 Dmitry Makovey wrote:
On September 19, 2012 15:20:17 Dmitry Makovey wrote:
Daniel, you saved my day - I thought that something like that should exist but I completely ommited sepgsql* set as I was under impression that it applied to a completely different functionality. I'll use that instead of my module. Thank you very much.
spoke too soon:
# setsebool sepgsql_enable_pitr_implementation On Could not change active booleans: Invalid boolean
so it sounds like it doesn't exist in RHEL? yet?
ok as per https://bugzilla.redhat.com/show_bug.cgi?id=858406 , Miroslav just added it, so it definitely doesn't exist yet. But it sounds like it is on it's way.. thank you Dan and Dominick for the help. I'll stick with my module for now.
What's the best way of tracking whether above changes made it into RHEL6 policies? Just the changelog?
Changelog and Bugzillas. The erratas will list all the bugs fixed in a RHEL update.
On 09/20/2012 01:31 AM, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/19/2012 05:35 PM, Dmitry Makovey wrote:
On September 19, 2012 15:27:43 Dmitry Makovey wrote:
On September 19, 2012 15:20:17 Dmitry Makovey wrote:
Daniel, you saved my day - I thought that something like that should exist but I completely ommited sepgsql* set as I was under impression that it applied to a completely different functionality. I'll use that instead of my module. Thank you very much.
spoke too soon:
# setsebool sepgsql_enable_pitr_implementation On Could not change active booleans: Invalid boolean
so it sounds like it doesn't exist in RHEL? yet?
ok as per https://bugzilla.redhat.com/show_bug.cgi?id=858406 , Miroslav just added it, so it definitely doesn't exist yet. But it sounds like it is on it's way.. thank you Dan and Dominick for the help. I'll stick with my module for now.
What's the best way of tracking whether above changes made it into RHEL6 policies? Just the changelog?
Changelog and Bugzillas. The erratas will list all the bugs fixed in a RHEL update. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlBaVeIACgkQrlYvE4MpobNMGgCfaIXknYd05F+iIHH+5zbJ8p7x X/IAnif2WZ8f66llAbUVGA/X+33+mIMs =HD7f
-----END PGP SIGNATURE-----
selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Thanks all. Will backport the latest solution to RHEL.
selinux@lists.fedoraproject.org