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
| 
