[refpolicy] [PATCH] Add all the missing _admin interfaces to sysadm

[dac.override@gmail.com (Dominick Grift)]

On Wed, Dec 03, 2014 at 11:12:00AM -0500, Christopher J. PeBenito wrote:
> On 12/3/2014 10:55 AM, Dominick Grift wrote:
> > On Wed, Dec 03, 2014 at 10:50:34AM -0500, Christopher J. PeBenito wrote:
> >> On 12/3/2014 10:44 AM, Christopher J. PeBenito wrote:
> >>> On 12/3/2014 10:29 AM, Jason Zaman wrote:
> >>>>
> >>>> On 3 Dec 2014 18:27, "Dominick Grift" <dac.override@gmail.com
> >>>> <mailto:dac.override@gmail.com>> wrote:
> >>>>>
> >>>>> On Wed, 2014-12-03 at 08:56 -0500, Christopher J. PeBenito wrote:
> >>>>>> On 12/3/2014 8:42 AM, Jason Zaman wrote:
> >>>>>>> On Wed, Dec 03, 2014 at 08:18:46AM -0500, Christopher J. PeBenito
> >>>> wrote:
> >>>>>>>> On 12/3/2014 7:28 AM, Jason Zaman wrote:
> >>>>>>>>> Lots of the foo_admin() interfaces were not applied to sysadm. This
> >>>>>>>>> patch adds all the ones that were missing. Interfaces are added
> >>>> together
> >>>>>>>>> with the matching _role() interface if it was already present.
> >>>>>>>>>
> >>>>>>>>> Make all && make validate passes, but anyone else that can run
> >>>> any test
> >>>>>>>>> suites on this would be appreciated too.
> >>>>>>>>
> >>>>>>>> I'm not opposed to this change, but I wonder about cases like these:
> >>>>>>>>
> >>>>>>>>> +
> >>>>>>>>> +optional_policy(`
> >>>>>>>>> + asterisk_admin(sysadm_t, sysadm_r)
> >>>>>>>>>   asterisk_stream_connect(sysadm_t)
> >>>>>>>>>  ')
> >>
> >>>>>> I think there is still the question, should the stream connect be added
> >>>>>> to the admin interface?
> >>>>>>
> >>>>>
> >>>>> I would argue, no
> >>>>>
> >>>>> The application use to stream connect should instead be confined and
> >>>>> _admin should run that application with a domain transition instead
> >>>>>
> >>>> I think admining something and using it are not necessarily the same so
> >>>> I agree with Dominick, they should be separate.
> >>>
> >>> I also agree.  The admin interfaces should have all of the rules needed
> >>> to admin the service, and that's it.  If that socket connect is not
> >>> related to an admin function, then it should remain separate.  I asked
> >>> the question since I was unsure why there was a stream connect.
> >>
> >> From the commit, Sven said:
> >>
> >>> Author: Sven Vermeulen
> >>> Date:   Mon Oct 3 21:24:38 2011 +0200
> >>>
> >>> Allow sysadm to interact with asterisk
> >>>
> >>> When administering asterisk, one often ran command is "asterisk -r"
> >>> which yields the asterisk CLI (when the asterisk server is running). To
> >>> be able to run this, you need asterisk_stream_connect privileges.
> >>>
> >>> Assign these privileges to the sysadm_r
> >>
> >>
> >> Which tells me that the stream connect should be added to the admin
> >> interface.
> >>
> > 
> > Where do you draw the line, are you now also adding all the permissions to sysadm_t that asterisk cli needs to run?
> > 
> > You dont see them now because sysadm_t is virtually unconfined_t already, but i bet the app needs permissions that a normal confined shell session does not need
> > 
> > why not just run the asterisk cli with a domain transition and associate these permission with at domain instead of sysadm_t?
> 
> See my other email.  If we further constrain sysadm_t, it may make more
> sense to do that, but at this time I don't think it's warranted.
> 
> 

Then it does not make sense to add all those _admin() interface calls to sysadm either in my view.

sysadm can already do all (most) those things on a lower level

So its pretty much just dupes; overhead

-- 
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20141203/aa026d3b/attachment-0001.bin