[refpolicy] [PATCH v2] kernel: missing permissions for confined execution

[guido@trentalancia.net (Guido Trentalancia)]

Of course I know that I can simply remove the "unconfined" module locally.

The point is that unconfined_domain() is very dangerous, eventually as dangerous as "permissive".

I still cannot think of a valid reason for keeping those calls... 

Regards, 

Guido 

On the 28th of December 2016 19:38:29 CET, Chris PeBenito <pebenito@ieee.org> wrote:
>On 12/27/16 15:42, Guido Trentalancia via refpolicy wrote:
>> Hello.
>>
>>> On the 27th December 2016 at 21.32 cgzones <cgzones@googlemail.com>
>wrote:
>>>
>>>
>>> Maybe we can crib from dwalsh:
>>>
>https://www.redhat.com/archives/fedora-selinux-list/2009-September/msg00014.html
>>>
>>> During the development phase between releases implement the
>unconfined
>>> domains via a permissive statement, which causes audits, instead of
>>> using the almost almighty unconfined_domain_noaudit interface?
>>
>> Yes, this sounds a good idea to me. I didn't know about this option,
>thanks for
>> pointing it out.
>>
>> We could keep that for a month or two and see what feedback comes
>from git users
>> and developers.
>>
>> I just don't know the timeline for the next release...
>
>A few things:
>
>1. There is no goal to eliminate all unconfined domains.  Any domains 
>(with the exception of unconfined_t) should only be optionally 
>unconfined.  If you don't want unconfined domains, remove the
>unconfined 
>module.  The existing unconfined domains are there on purpose, not 
>because the policies are "incomplete".
>
>2. Permissive domains are not allowed upstream in refpolicy, at any
>time.
>
>3. I'm trying to get on a roughly quarterly release schedule, so the 
>next release is in approximately one month.
>
>
>
>>> 2016-12-27 21:22 GMT+01:00 Guido Trentalancia via refpolicy
>>> <refpolicy@oss.tresys.com>:
>>>> Hello Christopher.
>>>>
>>>> Thanks for merging this. We should now have a fully functional
>kernel module
>>>> that,
>>>> as such, should not need the unconfined_domain interface calls
>anymore.
>>>>
>>>> Unfortunately, version 2 of this patch did not actually removed
>such
>>>> interface
>>>> call.
>>>>
>>>> Now, we have two options:
>>>>
>>>> - remove it in a new simple patch today or tomorrow;
>>>> - wait to remove it until after the next release, so that we can
>benefit
>>>> from
>>>> some
>>>>   more development-stage testing, just in case some kernel
>installation
>>>> around
>>>>   needs some other permission which did not show up in the tests
>that I
>>>> carried
>>>> out.
>>>>
>>>> For sure, we shall strive to get rid of it, for maximum security.
>>>>
>>>>> On the 27th of December 2016 at 16.52 Chris PeBenito
><pebenito@ieee.org>
>>>>> wrote:
>>>>>
>>>>>
>>>>> On 12/18/16 15:58, Guido Trentalancia via refpolicy wrote:
>>>>>> This patch adds missing permissions in the kernel module that
>prevent
>>>>>> to run it without the unconfined module.
>>>>>>
>>>>>> This second version improves the comment section of new
>interfaces:
>>>>>> "Domain" is replaced by "Domain allowed access".
>>>>>
>>>>> I thought that all of the added rules were for the initramfs. 
>Since
>>>>> only a few are, I'm fine without the tunable, so I merged this
>version
>>>>> of the patch.
>>>>>
>>>>>
>>>>>
>>>>>> Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
>>>>>> ---
>>>>>>  policy/modules/kernel/devices.if    |   56 +++++++++++++++
>>>>>>  policy/modules/kernel/files.if      |  131
>>>>>> ++++++++++++++++++++++++++++++++++++
>>>>>>  policy/modules/kernel/filesystem.if |   18 ++++
>>>>>>  policy/modules/kernel/kernel.if     |   18 ++++
>>>>>>  policy/modules/kernel/kernel.te     |   34 +++++++++
>>>>>>  policy/modules/kernel/terminal.if   |   20 +++++
>>>>>>  6 files changed, 277 insertions(+)
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy at oss.tresys.com
>> http://oss.tresys.com/mailman/listinfo/refpolicy
>>