* [refpolicy] [PATCH 0/2] Asterisk updates @ 2011-09-26 19:55 Sven Vermeulen 2011-09-26 19:57 ` [refpolicy] [PATCH 1/2] Asterisk admin must be able to run 'asterisk -r' Sven Vermeulen 2011-09-26 19:57 ` [refpolicy] [PATCH 2/2] Make sysadm an asterisk administrator Sven Vermeulen 0 siblings, 2 replies; 11+ messages in thread From: Sven Vermeulen @ 2011-09-26 19:55 UTC (permalink / raw) To: refpolicy Small patchset to support the "asterisk -r" command (asterisk CLI used often by administrators). Includes update on sysadm to become asterisk admin. Wkr, Sven Vermeulen ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] [PATCH 1/2] Asterisk admin must be able to run 'asterisk -r' 2011-09-26 19:55 [refpolicy] [PATCH 0/2] Asterisk updates Sven Vermeulen @ 2011-09-26 19:57 ` Sven Vermeulen 2011-09-26 20:23 ` Dominick Grift 2011-09-27 13:02 ` Daniel J Walsh 2011-09-26 19:57 ` [refpolicy] [PATCH 2/2] Make sysadm an asterisk administrator Sven Vermeulen 1 sibling, 2 replies; 11+ messages in thread From: Sven Vermeulen @ 2011-09-26 19:57 UTC (permalink / raw) To: refpolicy One of the most frequently ran commands by asterisk administrators is to run 'asterisk -r' to manipulate (through the asterisk socket) the asterisk daemon (sort-of asterisk-specific shell support). We allow the asterisk administrator (through asterisk_admin) to execute the asterisk binary (no domtrans) and connect through the socket. Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be> --- asterisk.if | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/asterisk.if b/asterisk.if index 8b8143e..3164850 100644 --- a/asterisk.if +++ b/asterisk.if @@ -62,6 +62,7 @@ interface(`asterisk_admin',` type asterisk_etc_t, asterisk_tmp_t, asterisk_log_t; type asterisk_var_lib_t; type asterisk_initrc_exec_t; + type asterisk_exec_t; ') allow $1 asterisk_t:process { ptrace signal_perms getattr }; @@ -89,4 +90,7 @@ interface(`asterisk_admin',` files_list_pids($1) admin_pattern($1, asterisk_var_run_t) + + can_exec($1, asterisk_exec_t) + asterisk_stream_connect($1) ') -- 1.7.3.4 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [refpolicy] [PATCH 1/2] Asterisk admin must be able to run 'asterisk -r' 2011-09-26 19:57 ` [refpolicy] [PATCH 1/2] Asterisk admin must be able to run 'asterisk -r' Sven Vermeulen @ 2011-09-26 20:23 ` Dominick Grift 2011-09-27 16:39 ` Sven Vermeulen 2011-09-27 13:02 ` Daniel J Walsh 1 sibling, 1 reply; 11+ messages in thread From: Dominick Grift @ 2011-09-26 20:23 UTC (permalink / raw) To: refpolicy On Mon, 2011-09-26 at 21:57 +0200, Sven Vermeulen wrote: > One of the most frequently ran commands by asterisk administrators is to > run 'asterisk -r' to manipulate (through the asterisk socket) the > asterisk daemon (sort-of asterisk-specific shell support). > > We allow the asterisk administrator (through asterisk_admin) to execute > the asterisk binary (no domtrans) and connect through the socket. In theory looks good but i wonder if this will work in practice since you may have tested it with sysadm_t that is not a good representation of reality. These admin interfaces shouldnt be called by sysadm_t, they should instead be used with userdom_base_user_template. like; mkdir myasteriskadm; cd myasteriskadm; echo "policy_module(myasteriskadm, 1.0.0)" userdom_base_user_template(myasteriskadm) role myasteriskadm_r; asterisk_admin(myasteriskadm_t, myasteriskadm_r) " > myasteriskadm.te; and then for example: echo "policy_module(mystaff, 1.0.0) gen_require(\` role staff_r, myasteriskadm_r; ') allow staff_r myasteriskadm_r;" > mystaff.te; semanage user -m -L s0 -r s0-s0:c0.c1023 -R "staff_r system_r myasteriskadm_r sysadm_r" -P user staff_u useradd -Z staff_u joe sudo -t myasteriskadm_t -r myasteriskadm_r /etc/init.d/asterisk start disclaimer: example have my have errors since i did it off the top of my mind. > > Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be> > --- > asterisk.if | 4 ++++ > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/asterisk.if b/asterisk.if > index 8b8143e..3164850 100644 > --- a/asterisk.if > +++ b/asterisk.if > @@ -62,6 +62,7 @@ interface(`asterisk_admin',` > type asterisk_etc_t, asterisk_tmp_t, asterisk_log_t; > type asterisk_var_lib_t; > type asterisk_initrc_exec_t; > + type asterisk_exec_t; > ') > > allow $1 asterisk_t:process { ptrace signal_perms getattr }; > @@ -89,4 +90,7 @@ interface(`asterisk_admin',` > > files_list_pids($1) > admin_pattern($1, asterisk_var_run_t) > + > + can_exec($1, asterisk_exec_t) > + asterisk_stream_connect($1) > ') -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110926/1463dc90/attachment.bin ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] [PATCH 1/2] Asterisk admin must be able to run 'asterisk -r' 2011-09-26 20:23 ` Dominick Grift @ 2011-09-27 16:39 ` Sven Vermeulen 2011-09-27 17:02 ` Dominick Grift 0 siblings, 1 reply; 11+ messages in thread From: Sven Vermeulen @ 2011-09-27 16:39 UTC (permalink / raw) To: refpolicy On Mon, Sep 26, 2011 at 10:23:06PM +0200, Dominick Grift wrote: > In theory looks good but i wonder if this will work in practice since > you may have tested it with sysadm_t that is not a good representation > of reality. These admin interfaces shouldnt be called by sysadm_t, they > should instead be used with userdom_base_user_template. I agree that role support here is important, but what is the rule when to add things to sysadm_t and when not? It also holds the apache_role... Wkr, Sven Vermeulen ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] [PATCH 1/2] Asterisk admin must be able to run 'asterisk -r' 2011-09-27 16:39 ` Sven Vermeulen @ 2011-09-27 17:02 ` Dominick Grift 2011-09-27 17:28 ` Sven Vermeulen 0 siblings, 1 reply; 11+ messages in thread From: Dominick Grift @ 2011-09-27 17:02 UTC (permalink / raw) To: refpolicy On Tue, 2011-09-27 at 18:39 +0200, Sven Vermeulen wrote: > On Mon, Sep 26, 2011 at 10:23:06PM +0200, Dominick Grift wrote: > > In theory looks good but i wonder if this will work in practice since > > you may have tested it with sysadm_t that is not a good representation > > of reality. These admin interfaces shouldnt be called by sysadm_t, they > > should instead be used with userdom_base_user_template. > > I agree that role support here is important, but what is the rule when to > add things to sysadm_t and when not? It also holds the apache_role... *_admin() interfaces arent your average roles. (i guess thats why they dont call them *_admin_role()) sysadmin is already a general purpose admin. sysadm can already restart any service and edit almost any file so adding asterisk_admin() does add much functionality other than the "asterisk -r". You can allow sysadm_t to run asterisk -r in other ways without including all the duplicate policy that you would by calling asterisk_admin for sysadm So, yes roles() should be called in the role layer modules but asterisk_admin or any other _admin interface is not such a role. its different, its specific to confined root. > Wkr, > Sven Vermeulen > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110927/8dc9a99c/attachment-0001.bin ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] [PATCH 1/2] Asterisk admin must be able to run 'asterisk -r' 2011-09-27 17:02 ` Dominick Grift @ 2011-09-27 17:28 ` Sven Vermeulen 0 siblings, 0 replies; 11+ messages in thread From: Sven Vermeulen @ 2011-09-27 17:28 UTC (permalink / raw) To: refpolicy On Tue, Sep 27, 2011 at 07:02:52PM +0200, Dominick Grift wrote: > *_admin() interfaces arent your average roles. (i guess thats why they > dont call them *_admin_role()) Hmm, okay [...] > So, yes roles() should be called in the role layer modules but > asterisk_admin or any other _admin interface is not such a role. its > different, its specific to confined root. Didn't know that, thanks. I think it is best to mark the binary as an application_exec_type then as you suggested, and use the stream connect. I'll have it tested to see if that works. Wkr, Sven Vermeulen ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] [PATCH 1/2] Asterisk admin must be able to run 'asterisk -r' 2011-09-26 19:57 ` [refpolicy] [PATCH 1/2] Asterisk admin must be able to run 'asterisk -r' Sven Vermeulen 2011-09-26 20:23 ` Dominick Grift @ 2011-09-27 13:02 ` Daniel J Walsh 2011-09-27 16:35 ` Sven Vermeulen 1 sibling, 1 reply; 11+ messages in thread From: Daniel J Walsh @ 2011-09-27 13:02 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/26/2011 03:57 PM, Sven Vermeulen wrote: > One of the most frequently ran commands by asterisk administrators > is to run 'asterisk -r' to manipulate (through the asterisk socket) > the asterisk daemon (sort-of asterisk-specific shell support). > > We allow the asterisk administrator (through asterisk_admin) to > execute the asterisk binary (no domtrans) and connect through the > socket. > > Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be> --- > asterisk.if | 4 ++++ 1 files changed, 4 insertions(+), 0 > deletions(-) > > diff --git a/asterisk.if b/asterisk.if index 8b8143e..3164850 > 100644 --- a/asterisk.if +++ b/asterisk.if @@ -62,6 +62,7 @@ > interface(`asterisk_admin',` type asterisk_etc_t, asterisk_tmp_t, > asterisk_log_t; type asterisk_var_lib_t; type > asterisk_initrc_exec_t; + type asterisk_exec_t; ') > > allow $1 asterisk_t:process { ptrace signal_perms getattr }; @@ > -89,4 +90,7 @@ interface(`asterisk_admin',` > > files_list_pids($1) admin_pattern($1, asterisk_var_run_t) + + > can_exec($1, asterisk_exec_t) + asterisk_stream_connect($1) ') An asterisk admin should not be running the application in his his own context, he should be allowed to restart it in the asterisk_t domain which is why we have asterisk_initrc_exec_t. And are moving towards using asterisk_systemctl() for systemd controls. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6ByYIACgkQrlYvE4MpobPLkgCgs7wvSQRK9e7JMeUELDtvSnUn 6GgAoKLKT27GVU28lapZHvC4bFTdLd0h =MdXu -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] [PATCH 1/2] Asterisk admin must be able to run 'asterisk -r' 2011-09-27 13:02 ` Daniel J Walsh @ 2011-09-27 16:35 ` Sven Vermeulen 2011-09-27 16:55 ` Dominick Grift 0 siblings, 1 reply; 11+ messages in thread From: Sven Vermeulen @ 2011-09-27 16:35 UTC (permalink / raw) To: refpolicy On Tue, Sep 27, 2011 at 09:02:58AM -0400, Daniel J Walsh wrote: > An asterisk admin should not be running the application in his his own > context, he should be allowed to restart it in the asterisk_t domain > which is why we have asterisk_initrc_exec_t. And are moving towards > using asterisk_systemctl() for systemd controls. Having stream_connect rights doesn't allow him to run the application in his own domain. What this patch offers is to allow the asterisk admin to run "asterisk -r" so he can get the CLI open. The CLI doesn't work if asterisk isn't running, and restarting it doesn't refresh the process (so it remains running in asterisk_t), it is more of a reload. The use of "asterisk -r" is often done by asterisk admins. We've asked a few of them to check if this is really necessary and they all agreed that having "asterisk -r" possible is a major requirement for asterisk administration. The use of the init script is indeed still necessary for stop and start operations as well as some general management activities, but administering asterisk is more than just those operational activities. Also, to reply to Dominick's suggestion to only have the asterisk_stream_connect for the asterisk admin, that won't work since he would still need can_exec rights on the asterisk_exec_t. Also, since he is asterisk admin, he'll need asterisk_admin() anyhow. Wkr, Sven Vermeulen ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] [PATCH 1/2] Asterisk admin must be able to run 'asterisk -r' 2011-09-27 16:35 ` Sven Vermeulen @ 2011-09-27 16:55 ` Dominick Grift 0 siblings, 0 replies; 11+ messages in thread From: Dominick Grift @ 2011-09-27 16:55 UTC (permalink / raw) To: refpolicy On Tue, 2011-09-27 at 18:35 +0200, Sven Vermeulen wrote: > On Tue, Sep 27, 2011 at 09:02:58AM -0400, Daniel J Walsh wrote: > > An asterisk admin should not be running the application in his his own > > context, he should be allowed to restart it in the asterisk_t domain > > which is why we have asterisk_initrc_exec_t. And are moving towards > > using asterisk_systemctl() for systemd controls. > > Having stream_connect rights doesn't allow him to run the application in his > own domain. What this patch offers is to allow the asterisk admin to run > "asterisk -r" so he can get the CLI open. The CLI doesn't work if asterisk > isn't running, and restarting it doesn't refresh the process (so it remains > running in asterisk_t), it is more of a reload. Yes sorry i overlooked that but still i think this may or may not be fixed better in a different way. What i assumed was that sysadm_t was allowed to run any exec_type (that would include asterisk_exec_t) but i looked wrong. sysadm_t can execute all application_exec_type instead and asterisk_exec_t is not that. So either you also add the can_exec() to sysadms role policy module or you make asterisk_exec_t an application_executable_file or you allow sysadm-t to run all exec_types. Which solution is best i am not sure, but i think i would prefer the application_executable_file(asterisk_exec_t) > The use of "asterisk -r" is often done by asterisk admins. We've asked a few > of them to check if this is really necessary and they all agreed that having > "asterisk -r" possible is a major requirement for asterisk administration. Sure and i agree this should be supported but that should not be achieved by calling asterisk_admin for sysadm_t because many of the rules in there are duplicate for sysadm sysadm is a general purpose admin role. So sysadm_t should be able to run asterisk -r (see above) the asterisk_admin() is for administrators with more specific roles (not as broad as sysadm) by having that interface we allow for the creation of these specific roles. (their just not installed by default) > The use of the init script is indeed still necessary for stop and start > operations as well as some general management activities, but administering > asterisk is more than just those operational activities. sysadm should be able to manage all of asterisk and except for running asterisk -r i believe it can. I did not say that allowing the can_exec() and stream_connect to asterisk_admin was a bad idea, i just said that i wonder if that is sufficient. What i did say is that asterisk_admin() should not be called by sysadm-t because sysadm_t is already allowed to restart any system service and manage almost any file. So adding that would for the most part be adding duplicate rules (except for the support for asterisk -r which we should support, just not by calling asteriaks_admin for sysadm_t) > Also, to reply to Dominick's suggestion to only have the > asterisk_stream_connect for the asterisk admin, that won't work since he > would still need can_exec rights on the asterisk_exec_t. Also, since he is > asterisk admin, he'll need asterisk_admin() anyhow. i am not saying that this policy should not be in asterisk_admin. i am saying that sysadm_t should not call asterisk_admin() instead allow sysadm to run asterisk_exec_t and allow sysadm to stream connect to asterisk. > Wkr, > Sven Vermeulen > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110927/d9baf52c/attachment.bin ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] [PATCH 2/2] Make sysadm an asterisk administrator 2011-09-26 19:55 [refpolicy] [PATCH 0/2] Asterisk updates Sven Vermeulen 2011-09-26 19:57 ` [refpolicy] [PATCH 1/2] Asterisk admin must be able to run 'asterisk -r' Sven Vermeulen @ 2011-09-26 19:57 ` Sven Vermeulen 2011-09-26 20:12 ` Dominick Grift 1 sibling, 1 reply; 11+ messages in thread From: Sven Vermeulen @ 2011-09-26 19:57 UTC (permalink / raw) To: refpolicy Give the asterisk administration role to the sysadm_r role. Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be> --- policy/modules/roles/sysadm.te | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/policy/modules/roles/sysadm.te b/policy/modules/roles/sysadm.te index 954417f..d9d6726 100644 --- a/policy/modules/roles/sysadm.te +++ b/policy/modules/roles/sysadm.te @@ -86,6 +86,10 @@ optional_policy(` ') optional_policy(` + asterisk_admin(sysadm_t, sysadm_r) +') + +optional_policy(` auditadm_role_change(sysadm_r) ') -- 1.7.3.4 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [refpolicy] [PATCH 2/2] Make sysadm an asterisk administrator 2011-09-26 19:57 ` [refpolicy] [PATCH 2/2] Make sysadm an asterisk administrator Sven Vermeulen @ 2011-09-26 20:12 ` Dominick Grift 0 siblings, 0 replies; 11+ messages in thread From: Dominick Grift @ 2011-09-26 20:12 UTC (permalink / raw) To: refpolicy On Mon, 2011-09-26 at 21:57 +0200, Sven Vermeulen wrote: > Give the asterisk administration role to the sysadm_r role. > > Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be> > --- > policy/modules/roles/sysadm.te | 4 ++++ > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/policy/modules/roles/sysadm.te b/policy/modules/roles/sysadm.te > index 954417f..d9d6726 100644 > --- a/policy/modules/roles/sysadm.te > +++ b/policy/modules/roles/sysadm.te > @@ -86,6 +86,10 @@ optional_policy(` > ') > > optional_policy(` > + asterisk_admin(sysadm_t, sysadm_r) > +') This should not be here. Its mostly duplicate. I think you might only need to add the asterisk_stream_connect() here if anything at all. > +optional_policy(` > auditadm_role_change(sysadm_r) > ') > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110926/4b9cf0f8/attachment.bin ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2011-09-27 17:28 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-09-26 19:55 [refpolicy] [PATCH 0/2] Asterisk updates Sven Vermeulen 2011-09-26 19:57 ` [refpolicy] [PATCH 1/2] Asterisk admin must be able to run 'asterisk -r' Sven Vermeulen 2011-09-26 20:23 ` Dominick Grift 2011-09-27 16:39 ` Sven Vermeulen 2011-09-27 17:02 ` Dominick Grift 2011-09-27 17:28 ` Sven Vermeulen 2011-09-27 13:02 ` Daniel J Walsh 2011-09-27 16:35 ` Sven Vermeulen 2011-09-27 16:55 ` Dominick Grift 2011-09-26 19:57 ` [refpolicy] [PATCH 2/2] Make sysadm an asterisk administrator Sven Vermeulen 2011-09-26 20:12 ` Dominick Grift
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.