From: russell@coker.com.au (Russell Coker) Date: Wed, 30 Sep 2009 17:56:56 +1000 Subject: [refpolicy] roles_unconfineduser.patch In-Reply-To: <4AC25BA7.1060502@redhat.com> References: <4A983C2C.8040507@redhat.com> <1254235446.10232.115.camel@gorn.columbia.tresys.com> <4AC25BA7.1060502@redhat.com> Message-ID: <200909301756.59551.russell@coker.com.au> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Wed, 30 Sep 2009, Daniel J Walsh wrote: > kernel_t, rpm_t, unconfined_t. ?We want these to be unconfined_domains no > matter what unconfined_t would be eliminated if you removed > unconfineduser.pp > > I don't see ways that you can realistically run with out kernel_t and rpm_t > being unconfined. We did have usable systems for years before the concept of an "unconfined domain" was invented. Of course we did occasionally run into problems like the kernel Oops on shutdown if kernel_t was not permitted to create a UDP socket. In a more general sense, rpm_t needs to be able to create files with few restrictions (we could restrict it from accessing /home but that would involve some pain). kernel_t needs to be able to mess with other processes and network operations in any way that it desires but should have no filesystem access other than that which is required to run init and modprobe (or maybe hotplug too - what's the latest plan for kernel support of new devices?). -- russell at coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog