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

Dominick Grift dominick.grift at gmail.com
Tue Sep 27 12:02:52 CDT 2011


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 


More information about the refpolicy mailing list