From: dwalsh@redhat.com (Daniel J Walsh) Date: Wed, 30 Sep 2009 08:49:26 -0400 Subject: [refpolicy] roles_unconfineduser.patch In-Reply-To: <200909301756.59551.russell@coker.com.au> References: <4A983C2C.8040507@redhat.com> <1254235446.10232.115.camel@gorn.columbia.tresys.com> <4AC25BA7.1060502@redhat.com> <200909301756.59551.russell@coker.com.au> Message-ID: <4AC353D6.8040209@redhat.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 09/30/2009 03:56 AM, Russell Coker wrote: > 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?). > Do you use NFS? AFS? Kernel threads need access to the file system