From: mgrepl@redhat.com (Miroslav Grepl) Date: Fri, 03 Apr 2015 16:29:38 +0200 Subject: [refpolicy] [PATCH] Add all the missing _admin interfaces to sysadm In-Reply-To: <547F3E95.4060105@tresys.com> 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> <547F3E95.4060105@tresys.com> Message-ID: <551EA3D2.30500@redhat.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 12/03/2014 05:47 PM, Christopher J. PeBenito wrote: > 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. > > I believe both of you are right. But you will have always CLI tools which need to have access from sysadm_t to a domain. We would need to take care also about these tools. -- Miroslav Grepl Software Engineering, SELinux Solutions Red Hat, Inc.