On Tue, 2004-04-06 at 17:26 -0400, Gene C. wrote: > On Tuesday 06 April 2004 16:43, Colin Walters wrote: > > > 5) Third-party daemons. Looking at the current policy, a lot of > > > services have their own domains, and for good reason. However, in order > > > to do this, every single Fedora service has to have it's domain > > > information added to the policy source in a number of places. And that > > > information has to be present regardless of whether or not the service > > > is actually installed. Third-party daemons now must patch multiple > > > files in the policy sources, compile and load the new policy, or just > > > live with whatever domain options they are given (and live with the fact > > > that they have only slightly more security than the simple > > > user-group-other model). > > > > There are a few solutions to this. One I've been thinking of is to have > > an unlimited_t type (and corresponding unlimited_exec_t). Then when you > > install a third-party daemon, the system administrator could just run: > > > > chcon -t unlimited_exec_t /path/to/daemon > > > > As its name implies, unlimited_t would have all permissions. Then you > > could later create a policy and secure the daemon. Or maybe we should > > call it unsecured_t. > > Whatever you want to call it but your idea sounds good to me. The idea of a > third party package screwing with my security policy really bothers me. The > third party package may want to make some suggestions as to what it needs but > it should be up to the administrator of the system to implement those. > > As time progresses you (Red Hat) may be able to incorporate policy to handle > some of the more popular packages. For example, this is already done to some > extent for vmware. I actually pretty strongly disagree here. I think that we need to move to where policy for various daemons is included and maintained along with the daemon. Otherwise, we have a never-ending battle of one huge monolithic package that will end up with bizarre dependencies on apps. Managing that is going to be a nitemare in the long-term. Think of the situation where you want to upgrade your sendmail package, but to upgrade your sendmail package, you need the new policy that has information for the new way sendmail is split up but *that* requires you to upgrade something else... it can spiral out of control very very quickly. There's a reason we don't, eg, put all of the German translations for everything we ship in, eg, a translations-german package. It just doesn't scale maintenance wise. And that's completely disregarding third party packaging. You say that you don't want third party packages screwing with your security policy, but the fact of the matter is that they do so *right now*. The onus is on the user to either investigate the security implications of installing a particular package or trust the developer to do so for you. SELinux just adds another layer to this. Jeremy
