Stephen Smalley wrote:
On Thu, 2004-08-26 at 05:37, Jeff Johnson wrote:
Malicious code from untrusted package problem not going to be solved by rpm_script_t alone afaict either.
Right. We still need a mechanism for distinguishing among packages and running scriptlets in different domains based on either some property of the package (the authority that signed it) or some knowledge of the admin (i.e. he specifies the desired scriptlet domain for all packages obtained from a given repository in his yum.conf or similar).
My current thoughts are to pass to libselinux
a) the result (OK/NOKEY/UNTRUSTED/BAD) of the package header signature verify.
b) the contained file manifest.
and have libselinux return
a) the file contexts to be applied.
b) the exec context to use for that package's scriptlets.
That info permits libselinux to have full control of what rpmlib can/will do to
establish policy for packe files and scripts.
I can add the signature fingerprint id, but then libselinux and /var/lib/rpm/Pubkeys
would have different conceptions of keyring, and (for better or worse) rpmlib
is better positioned to decide what input is valid than libselinux is.
If necessary, I suppose I can pass signature/pubkey/blob if libselinux wishes to do it's
own crypto. I suspect that I could even wire the call to libselinux with a return
code so that libselinux could control whether rpm was permitted to read any given
header.
Say when, not my call. Perhaps a week's work, another week to stabilize on fc3 packaging.
Otherwise crypto is hard slow design, known.
73 de Jeff
