|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Hi, As we agreed during the LSS Iet's try to define a unified set of security hooks for rpm. I have promised to post the set of hooks that we are proposing. I think we can try first to agree on the hooks and they arguments and then agree about their place. I can make the needed adjustments on the actual code. Also I have been thinking that since we are talking more and more about stackable LSMs, then security plug-in interface for rpm should support multiple security plug-ins in case package comes with configurations for a number of LSMs (also things like IMA/EVM setup can be moved to a separate plug-in). What do you think about it? All current hooks return rpmRC error code, which is RPMRC_OK, if no errors are detected and RPMRC_FAIL, if failure is detected and installation must be aborted. And here are the actual hooks: 1. rpmRC SECURITYHOOK_INIT_FUNC(rpmts ts, const char *opts) This hook should be used by the security plug-in to initialize itself and its data. 2. rpmRC SECURITYHOOK_CLEANUP_FUNC(void) This hook should be used by the plug-in to free any allocated memory and finish its execution. 3. rpmRC SECURITYHOOK_PRE_TSM_FUNC(rpmts _ts) This hook is called before the beginning of rpm transaction and allows the plug-in to perform the pre-checks on the group of packages to be installed. 4. rpmRC SECURITYHOOK_POST_TSM_FUNC(rpmts _ts) This hook is called after the rpm transaction has finished. It allows the security plug-in to perform any post-transaction checks or additional processing. 5. rpmRC SECURITYHOOK_PRE_PSM_FUNC(rpmte _te) This hook is called before the installation/removal of a single package begins. If the rpm transaction contains multiple packages, this hook will be called for each package separately. Using this hook rpm security plugin is able to do any processing per each package. 6. rpmRC SECURITYHOOK_POST_PSM_FUNC(rpmte _te, int rpmrc) This hook is called after the installation/removal of a single package. If the rpm transaction contains multiple packages, this hook will be called for each package separately. This can be a good place to do some verification that installation went successfully and perform needed cleanups per package-basis if needed. 7. rpmRC SECURITYHOOK_SCRIPT_EXEC_FUNC(ARGV_const_t argv) This hook is called before any maintainer script is executed and hook gets full set of command line script parameters. It is a responsibility of the hook to call execution of the script and provide the exit status. This hook should be used by a security plug-in to setup a proper security context for the script execution and then execute the script. 8. rpmRC SECURITYHOOK_FSM_OPENED_FUNC(const char* dirName, const char* baseName) This is first of the three file hooks that are needed by the security plugin to perform an operation of a certain file from the package. This hook is called before the file is read from the archive. The dirName and baseName allow to reconstruct the path of the file to be place to the filesystem. 9. rpmRC SECURITYHOOK_FSM_UPDATED_FUNC(const struct stat * st, char *buf, size_t len) This is the second of the file hooks. It is called a number of times depending on the file length every time a new chunk of file is read from the archive to the buffer. The actual buffer and its length is provided in the parameters. 10. rpmRC SECURITYHOOK_FSM_CLOSED_FUNC(int rpmrc) The last file hook allows the plugin to finish the file processing. It is called once per each file from the package and after the file has been placed to the filesystem. Can be used to label the file. 11. rpmRC SECURITYHOOK_VERIFY_FUNC(rpmKeyring keyring, rpmtd sigtd, pgpDigParams sig, rpmRC rpmrc) The main purpose of this hook is to give ability for a security plugin to perform its own independent (and potentially stricter) control over the package verification. It also allows a security plugin to store the information about the package source in its internal metadata (potentially stricter controlled) in order to enforce its own policies. In MSM security plug-in this hook is used to verify the SW source of the package using its internal database of trusted keys. The primary reason for having its own database is an ability to strictly control the software keys and don't mix them with other keys that might be on the system's keyring. In Tizen OS in the future there is a plan to use a separate Certificate Manager in order to store and manage the system code certificates. This hook can also use the keyring to perform similar to rpm verification of package, if no internal database of keys exist. 12. rpmRC SECURITYHOOK_FILE_CONFLICT_FUNC(rpmts ts, rpmte te, rpmfi fi, Header oldHeader, rpmfi oldFi, int rpmrc) This hook can be used by the plug-ins in order to enforce stricter control over the case when files on the disk can be overwritten by newly installed packages. The basic rpm doesn't allow such cases by default, but it has an option ("--replacefiles") that allows such overwriting to happen. However from the security point of view it should not be possible to substitute system binaries or components from a package that is coming from an untrusted source. Such hook provides a possibility to monitor such cases and deny the installation. Best Regards, Elena. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
[Fedora Users] [Fedora Legacy] [Fedora Desktop] [Yosemite Photos] [Yosemite News] [Yosemite Campsites] [KDE Users] [Gnome Users]