On Tue, 2004-10-12 at 09:27, Jeff Johnson wrote: > Not so much irony as difficult coordination. Compiling "rpm_script_t" > into rpm is > gonna be difficult coordination, and now that there are two behaviors, > support > is gonna get messy too. > > I'm open for better ideas, would like to have the choice of > "rpm_script_t" exec type in libselinux > even though mechanism is of necessity in rpm. > > How about a simple routine, I pass the interpreter (i.e. "/bin/sh" or > "/sbin/ldconfig"), and > libselinux gives me the IDENTITY:ROLE:TYPE to set. > > Even better, rpm will fork, then give libselinux argv[0] before doing > execve. Then libselinux > can do whatever it wants. > > You can have argv, not just argv[0] if you want too. ;-) > > Sound like a plan? Sounds reasonable. libselinux would presumably fetch the context of the interpreter/helper via getfilecon(), then call security_compute_create() to see if there is a default transition defined for the interpreter/helper, and if not, then explicitly setexeccon() to rpm_script_t. Might want to also pass the result of the signature verify as a further input in selecting the desired domain. -- Stephen Smalley <sds@xxxxxxxxxxxxxx> National Security Agency
