[refpolicy] [PATCH 1/2] Asterisk admin must be able to run 'asterisk -r'

Dominick Grift dominick.grift at gmail.com
Tue Sep 27 11:55:58 CDT 2011


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 


More information about the refpolicy mailing list