Re: [Rpm-maint] Tizen rpm security plug-in interface
Hi, I would like to give an update on the status of the rpm security plugin interface. I have moved the patch to the latest rpm code and will be upgrading it weekly form now on. I have fixed the issue that you commented last time with FSM hooks that were passing the fsm structure in full to the plug-in and now it passes only the needed information. Also, I have changed some parts related to the signature handling in the plug-in itself. The code is here in one commit (together with the plug-in code to illustrate the use of hooks): https://github.com/ereshetova/rpm/commit/5f4bb06a617fefceeb2656de3f11d9dd657 e352c I would really like to bring this code to shape now (since I have time right now) and would be very thankful for all the comments! Please don't pay attention to the cosmetics yet, only to the functionality since this is far from being a ready patch :) Could you also suggest who is currently maintaining (if any) the SElinux part in rpm? I would like to discuss if the current set of hooks is enough or smth needs modification. I also updated the wiki (https://github.com/ereshetova/rpm/wiki ) and made a separate page for the hooks description: https://github.com/ereshetova/rpm/wiki/Security-Hooks-for-rpm Best Regards, Elena. -Original Message- From: rpm-maint-boun...@lists.rpm.org [mailto:rpm-maint-boun...@lists.rpm.org] On Behalf Of Reshetova, Elena Sent: Tuesday, November 01, 2011 12:52 PM To: Panu Matilainen Cc: rpm-maint@lists.rpm.org; Ware, Ryan R Subject: Re: [Rpm-maint] Tizen rpm security plug-in interface Hi Panu, Thank you for the reply! Unfortunately from time to time I have to start my mails to some people with exactly same words, so I understand very well that you mean. I personally think that selinux needs aren't very much different than our needs and we can come up with a set of security hooks that should be enough for both. Do you know if selinux people or people who made selinux implementation for rpm will be willing to collaborate with us to help defining a sound set of hooks or to verify that set we will be defining is suitable for them? Now about answering your questions about the hooks. I have written a short summary of how hooks are used or reasoning behind them. I am also attaching the whole patch, where the hooks are implemented that you can look to the implementation of hooks themselves. __ +RPMSECURITY_GET_HOOK_FUNC(SECURITYHOOK_INIT_FUNC); This is basic initialization function for the plug-in. +RPMSECURITY_GET_HOOK_FUNC(SECURITYHOOK_FILE_CONFLICT_FUNC); The reason why this hook is needed is rather simple. Yes, rpm doesn't allow this by default, but since we enforce mandatory access control, then even if the user uses force option, we want to make sure that for example some important system executables or files can't be overwritten. The example of the attack it is guarding against is that user can try to install a package that overwrites sensitive system settings file that can allow him to circumvent security. This attack can be very typical for the attacker models, where user of the device isn't trusted enough to modify system settings or security policies. In msm this hook is used to make populate a hash list of file path conflicts with a new conflict information (like a path and sw source of the package that conflicts). Later, when package signature is verified and we are sure where the package comes from, the plug-in can make a decision whatever this package introduces a security conflict and installation must be aborted. +RPMSECURITY_GET_HOOK_FUNC(SECURITYHOOK_PRE_TSM_FUNC); This hook isn't really used by msm apart that basic check is done on internal structure existence. However, I think the hook may be useful since other security plug-ins may want to include some checks before bunch of packages are installed. +RPMSECURITY_GET_HOOK_FUNC(SECURITYHOOK_VERIFY_FUNC); The reason for this hook comes from the fact that plugin maintains what we call a device security policy that arranges known software sources in a form of a tree with different trust levels assigned. This is needed because gpg can't give us any order and we want to build a hierarchical tree of software sources and define the rules, if package from one source can overwrite a package from another. Based on this information, a lot of decisions are done, if package should be installed or not and if applications from this package are allowed to request certain types of accesses on the platform. So, in this hook, msm plug-in simply maps the package to one of its internal software sources and does an additional verification of the key fingerprint. It is currently stored in device security policy too, but I think this part can be removed from plug-in later when proper certificate manager is used to secure code signing certificates. Does this explain a bit better the need of this hook? I also have things written that explain what
Re: [Rpm-maint] Tizen rpm security plug-in interface
Hi Panu, I have finally managed to bring the code repository to the place where everyone should be able to access. Also in the wiki of the project, there is some documentation explaining the design. I will be updating it still today (one more different wiki format to convert :( ). The master branch in the repo corresponds to the upstream rpm repository, the branch security-changes contains the security changes (including the plug-in implementation) put on top of the upstream branch. Let me know if you have any questions! https://github.com/ereshetova/rpm/ Best Regards, Elena. -Original Message- From: rpm-maint-boun...@lists.rpm.org [mailto:rpm-maint-boun...@lists.rpm.org] On Behalf Of Reshetova, Elena Sent: Tuesday, November 01, 2011 12:52 PM To: Panu Matilainen Cc: rpm-maint@lists.rpm.org; Ware, Ryan R Subject: Re: [Rpm-maint] Tizen rpm security plug-in interface Hi Panu, Thank you for the reply! Unfortunately from time to time I have to start my mails to some people with exactly same words, so I understand very well that you mean. I personally think that selinux needs aren't very much different than our needs and we can come up with a set of security hooks that should be enough for both. Do you know if selinux people or people who made selinux implementation for rpm will be willing to collaborate with us to help defining a sound set of hooks or to verify that set we will be defining is suitable for them? Now about answering your questions about the hooks. I have written a short summary of how hooks are used or reasoning behind them. I am also attaching the whole patch, where the hooks are implemented that you can look to the implementation of hooks themselves. __ +RPMSECURITY_GET_HOOK_FUNC(SECURITYHOOK_INIT_FUNC); This is basic initialization function for the plug-in. +RPMSECURITY_GET_HOOK_FUNC(SECURITYHOOK_FILE_CONFLICT_FUNC); The reason why this hook is needed is rather simple. Yes, rpm doesn't allow this by default, but since we enforce mandatory access control, then even if the user uses force option, we want to make sure that for example some important system executables or files can't be overwritten. The example of the attack it is guarding against is that user can try to install a package that overwrites sensitive system settings file that can allow him to circumvent security. This attack can be very typical for the attacker models, where user of the device isn't trusted enough to modify system settings or security policies. In msm this hook is used to make populate a hash list of file path conflicts with a new conflict information (like a path and sw source of the package that conflicts). Later, when package signature is verified and we are sure where the package comes from, the plug-in can make a decision whatever this package introduces a security conflict and installation must be aborted. +RPMSECURITY_GET_HOOK_FUNC(SECURITYHOOK_PRE_TSM_FUNC); This hook isn't really used by msm apart that basic check is done on internal structure existence. However, I think the hook may be useful since other security plug-ins may want to include some checks before bunch of packages are installed. +RPMSECURITY_GET_HOOK_FUNC(SECURITYHOOK_VERIFY_FUNC); The reason for this hook comes from the fact that plugin maintains what we call a device security policy that arranges known software sources in a form of a tree with different trust levels assigned. This is needed because gpg can't give us any order and we want to build a hierarchical tree of software sources and define the rules, if package from one source can overwrite a package from another. Based on this information, a lot of decisions are done, if package should be installed or not and if applications from this package are allowed to request certain types of accesses on the platform. So, in this hook, msm plug-in simply maps the package to one of its internal software sources and does an additional verification of the key fingerprint. It is currently stored in device security policy too, but I think this part can be removed from plug-in later when proper certificate manager is used to secure code signing certificates. Does this explain a bit better the need of this hook? I also have things written that explain what plug-in does internally with pictures and etc. I hope I will be able to share this with you very soon. I am not sure what you meant with this: One thing I would've kinda expected but dont see here is a hook into package verification (ie rpm --verify), where a security plugin could check that whats on the system matches expectations for the extra security data. +RPMSECURITY_GET_HOOK_FUNC(SECURITYHOOK_PRE_PSM_FUNC); This is one of the most important hooks (before actual package installation), where the plug-in is able to analyse the embeeded security information in the package and make a decision whatever the package should be installed
