Russell Coker wrote:
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.
Pain and the need for limiting rpm_cript_t well understood, not nudging ;-)
Adding --noscripts --notriggers automagically to each package not signed with
trusted signature is an alternative that starts to avoid a lot of selinux pain. And,
since very few 3rd party add-on packages are essential to system integrity, ther
are few consequences running the scripts after that fact in an entirely different
domain of execution.
There are still issues with trojan'ed files in payload, forcing chmod -x or chmod 000
might start to limit damage.
So it's the logical connection that leads from
rpm_script_t has too much access
to
rpm needs multiple domains based on signature
that I am seeking. selinux is not the only way to limit damage if you catch my drift.
But selinux is gonna need a trust proof mark. What is done with the proof mark is
different question.
73 de Jeff
