On Thu, 11 Mar 2004 00:48, Jeff Johnson <n3npq@xxxxxxxxx> wrote: > > At the moment rpm_script_t has access to so much that there's no point in > > trying to impose any serious restriction on it. > > > > I suspect that limiting rpm_script_t in any significant way will have > > to wait until we have multiple domains for rpm for installing packages > > with different signatures. > > What is the logical connection between > rpm_scriptlet_t has too much access. > and > rpm needs multiple domains based on signature "trust". > > Are there alternatives is what I'm asking. Currently we have no control over what can be done by scriptlets, and no control over how it's done. Some operations can be performed in several ways. For the packages that we develop we can develop proceedures for how to do these things that require the minimum of access. For the packages developed by other people they will have to get used to the idea that some of the people who use their packages will not trust scriptlets that they want to run, and therefore they should design them to do the minimum amount of work. When we start getting that under control we can do something about limiting rpm_script_t. But at the moment it wants to do everything, and there's little we can do about it without breaking heaps of rpms. We have enough pain at the moment. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
