From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Wed, 3 Dec 2014 11:47:17 -0500
Subject: [refpolicy] [PATCH] Add all the missing _admin interfaces to
 sysadm
In-Reply-To: <20141203162852.GB14237@e145.network2>
References: <1417609724-28437-1-git-send-email-jason@perfinion.com>	<547F0DB6.2060501@tresys.com>	<20141203134221.GA20778@meriadoc.Home>	<547F168F.2000109@tresys.com>	<20141203153942.GA29001@e145.network2>	<547F355C.3030902@tresys.com>
	<20141203162852.GB14237@e145.network2>
Message-ID: <547F3E95.4060105@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 12/3/2014 11:28 AM, Dominick Grift wrote:
> On Wed, Dec 03, 2014 at 11:07:56AM -0500, Christopher J. PeBenito
> wrote:
>> On 12/3/2014 10:39 AM, Dominick Grift wrote:
>>> On Wed, Dec 03, 2014 at 08:56:31AM -0500, Christopher J.
>>> PeBenito wrote:
>>>>>> 
>>>>>> 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) ')
>>>>>> 
>>>>>> Since I would assume that the admin interface would
>>>>>> already include the existing rule.
>>>>> 
>>>>> Bacula_admin does indeed call _run_admin so i'll take that
>>>>>  away, asterisk does not call _stream_connect so that one
>>>>> is correct. I will
>>>> 
>>>> I think there is still the question, should the stream
>>>> connect be added to the admin interface?
>>>> 
>>> 
>>> In my opinion where refpolicy went wrong is by allowing
>>> confined user domains this low level access in the first place
>>> shells do not stream connect, applications do.sysadm is a
>>> strict domain and so it should run the app that stream connects
>>> in the apps domain with a domain transition if that makes
>>> sense.
>>> 
>>> That is strict. Anything else is "drunken unconfined" in my
>>> view, or at least a compromise.
>>> 
>>> In my vision confined users should be strictly enforced (least
>>>  privilege) or at least as much as possible
>> 
>> I understand your position, but I believe the (IMO modest) gains
>> don't outweigh the additional complexity cost.  In this case, if
>> your admin is abusing their privileges, then there is a worse
>> problem.  I think a more effective confinement would be
>> eliminating sysadm's blanket manage access on basically the
>> entire filesystem.  If all these admin interfaces work well, all
>> that access won't be necessary.
> 
> Its not just about abuse its about containing processes. Programs
> have flaws
> 
> If you run those programs in one big privileged domain than those
> processes can affect everything else it has access to.
> 
> I rather have a highly complex policy that does what it say's on
> the label and is applicable, than a slighty less highly complex
> policy that is basically a compromise that sets a sub-optimal
> precedence.
> 
> Anyhow you made your point, and i made my point. Lets just agree to
> disagree.

I don't think we actually disagree in the long term.  I've always
wanted to remove access from sysadm_t.  Once that happens, it probably
will be much more obvious and compelling to add more domains for admin
programs.  Since further constraining sysadm_t is a massive change,
adding calls to the admin interfaces will be necessary to ensure
expected behavior.  It's a multi-step process.


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com