From: pebenito@ieee.org (Chris PeBenito) Date: Wed, 28 Dec 2016 13:38:29 -0500 Subject: [refpolicy] [PATCH v2] kernel: missing permissions for confined execution In-Reply-To: <1269539026.17966.1482871356455.JavaMail.open-xchange@popper10.register.it> References: <1482021787.10349.1.camel@trentalancia.net> <1482094724.22132.12.camel@trentalancia.net> <8317c7e0-7d87-6726-837c-1c39b0bfb8c1@ieee.org> <1078174712.17762.1482870141948.JavaMail.open-xchange@popper10.register.it> <1269539026.17966.1482871356455.JavaMail.open-xchange@popper10.register.it> Message-ID: <1f499ba0-b107-ff5a-ea13-1c008bc9ceda@ieee.org> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 12/27/16 15:42, Guido Trentalancia via refpolicy wrote: > Hello. > >> On the 27th December 2016 at 21.32 cgzones 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 >> : >>> 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 >>>> 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 >>>>> --- >>>>> 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 > -- Chris PeBenito