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

Miroslav Grepl mgrepl at redhat.com
Fri Apr 3 14:29:38 UTC 2015

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.

More information about the refpolicy mailing list