From: dominick.grift@gmail.com (Dominick Grift) Date: Sat, 15 Sep 2012 20:19:03 +0200 Subject: [refpolicy] [PATCH] Add Debian location for rtkit-daemon daemon In-Reply-To: References: <1347488050-19736-1-git-send-email-bigon@debian.org> <1347538790.2915.20.camel@d30.localdomain> <50520213.40902@redhat.com> <1347552374.2915.27.camel@d30.localdomain> <20120915133543.7a7857e0@fornost.bigon.be> Message-ID: <1347733143.2915.45.camel@d30.localdomain> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Sat, 2012-09-15 at 20:08 +0200, Sven Vermeulen wrote: > > On Sep 15, 2012 1:35 PM, "Laurent Bigonville" wrote > > Shouldn't we add some comments to keep track of distro specific > paths? > > Otherwise, if at some point, we want to make some cleanup it might > > become difficult to track if a path is still required. > > You even have this 'problem' for non-distro specific locations, such > as locations that change with newer program releases. OK, we make it a > bit worse here, but I think this is minor compared to the obsolete > locations due to older software releases. > > I think that if we look at locations module by module, we should be > able to clean up things. However, lots of locations are mentioned in > corecommands and libraries. Those might be more difficult to relate. > Which was why I suggested to perhaps allow bin/lib in module specific > fc files earlier. I just encountered something related today when i was porting stuff from fedora to contrib. The afs module was basically not used in fedora because fedora has the entry files in a location that was not in the file context file. Anyways i just added those and left the old stuff because we need to consider backwards compatibility. So i am saying, for now not to worry about obsolete file contexts, you never know who still have files in old locations. Thats also another thing that sucks, the chances we find such issues that i described above are slim because by default anything that initrc runs get run in a unconfined domain if it has a generic executable file type. So if you dont know where to look, its hard to determine whether policy is actually enforced or whether the app runs unprotected. The only way to figure that out is to disable the unconfined module. or to review each policy module carefully as i am doing. > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy