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 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 or not. + RPMSECURITY_GET_HOOK_FUNC(SECURITYHOOK_SCRIPT_EXEC_FUNC); Yes, this one as you noted is pretty obvious: needed to be able to execute maintainer scripts with the right security context. It is empty in the implementation now, because I have been concentrating on other hooks, but implementation will be quite similar to this old mssf implementation: http://meego.gitorious.org/meego-platform-security/rpm/blobs/taho_dev-4.9.x/ security/mssf.c#line438 + RPMSECURITY_GET_HOOK_FUNC(SECURITYHOOK_FSM_OPENED_FUNC); This hook is used for two purposes: * clear out the file conflicts and if conflict isn't allowed, return a failure * if everything is ok, initialise the hash function for calculating the reference hash. + RPMSECURITY_GET_HOOK_FUNC(SECURITYHOOK_FSM_UPDATED_FUNC); + RPMSECURITY_GET_HOOK_FUNC(SECURITYHOOK_FSM_CLOSED_FUNC); These two hooks are used to calculate the hash and store this info for future when reference hash can be put to extended attributes. The reason for calculating the hash per file and storing them in extended attributes is to be able to maintain the file integrity and setup attributes for another mainstream project: IMA/EVM. It isn't about access control, but it is a security feature (integrity) and our plug-in in the future hopefully will be doing both. Now, about passing fsm to these functions: if you look the code, we currently extract things, like fsm->dirName, fsm->baseName, fsm->path, fsm->digestalgo and also use the structure to store the computed digest itself. I think this can be made better and mode independent of actual rpm, but I haven't had a chance to look how to improve this part of code. What would you suggest to be passed for such needs from the rpm? + RPMSECURITY_GET_HOOK_FUNC(SECURITYHOOK_POST_PSM_FUNC); This hook mostly does some post checks, but also does one important job of setting the extended attributes on files installed from packages. In our case we need to setup various SMACK extended attributes, in case of selinux, it would be SELINUX attributes and etc. One trouble I have with this hook is that what should be done, if for some reasons setting of extended attributes fails? Currently behaviour isn't correct, because even if plugin returns in this hook that smth has failed, from rpm point of view package is already installed and there is no way back. From security point of view, it is very very bad, because we have some files on filesystem without proper extended attributes. What do you think is the right approach here: can we patch rom further that if this hook returns failure, it rolls back package installation? + RPMSECURITY_GET_HOOK_FUNC(SECURITYHOOK_POST_TSM_FUNC); Similarly to pre_tsm check: not used, but I think can be utilized by other security plug-ins or even msm plug-in in the future. + RPMSECURITY_GET_HOOK_FUNC(SECURITYHOOK_CLEANUP_FUNC); Cleaning up function for the plug-in. ___________________________________ I also think this can be added: >" 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." Indeed, this might be a useful check to do in addition. I will try to think about how to add it. And sure, all unrelated stuff has to be removed from patch. I was really just sending this for discussion and was a bit lazy of manually cleaning that parts in the beginning. I am attaching a full patch for now, but I would be much more happy just to send you a link to the repo (but unfortunately I have to figure out infrastructure issues first :( ). Best Regards, Elena -----Original Message----- From: Panu Matilainen [mailto:pmati...@laiskiainen.org] Sent: Friday, October 28, 2011 12:19 PM To: Reshetova, Elena Cc: rpm-maint@lists.rpm.org; Ware, Ryan R Subject: Re: [Rpm-maint] Tizen rpm security plug-in interface On 10/10/2011 04:00 PM, Reshetova, Elena wrote: > Hi, > > Let me make first a short introduction and some explanation to you > about the rpm > security related work we have been doing recently at Intel. > I hope we can collaborate on this in the future and help to put good > enablers in rpm for security purposes. Hi, and apologies for the late late reponse (starting to be my rpm-maint hallmark, sigh) > Some history first: > January this year, there was a set of patches posted from Tero Aho, > you can find them in archives: > http://lists.rpm.org/pipermail/rpm-maint/2011-January/002980.html > > I can see that even two tags were reserved for MSSF in rpm tags: > RPMTAG_MSSFMANIFEST and RPMTAG_MSSFDOMAIN. > > These patches were intended for wiring a MSSF rpm security plug-in for > MeeGo that would contain a rich set of security functionality, like > setting up security policies for installed packages, labelling xattr > for Smack and IMA and etc. I can provide more detailed description of > functionality, if needed. > > As you probably heard, LiMo and MeeGo had merged into a new project, > called Tizen (https://www.tizen.org/). > This didn't eliminate by any means the need of security and similar > security functionality that we needed in MeeGo related to rpm. > > So, our needs are still the same: we need to have a certain set of > hooks in rpm during different phases of rpm installation that can be > then implemented inside an rpm security plug-in. The hooks themselves > didn't change, but we did change their realisation inside the plug-in, > because we will be using a different security framework. > > > I would like to get your opinion about the hooks' position in rpm > code. I have just today rebased them to rpm master brunch. Lets put it this way: with this work, I sense an opportunity to push the currently built-in selinux context labeling code into a plugin. Which is something I'd love to see. > Please consider this not as ready patch, but more like code for the > initial discussion. > I have excluded for now the code of the plugin itself for simplicity. More detailed description (especially the "why" part - see below) and a pointer to the plugin source itself to get an idea what sort of things its doing would be nice for starters. I'd expect there to be certain amount of overlap with selinux needs, and I would want to see MSSF and selinux share the same infrastructure (comparison is apples to oranges atm as part of selinux support is built-in and other parts in a collections plugin, which is a rather different beast). Looking at the hooks defined by the security plugin... What is the intended use case of SECURITYHOOK_FILE_CONFLICT_FUNC? Rpm doesn't allow conflicting files to be installed unless forced, so this seems a bit strange and/or redundant to me. Ditto for SECURITYHOOK_VERIFY_FUNC additional signature checking hook and the "allows calculating hashes" reference wrt the FSM-hooks - what's the rationale for these seemingly redundant things? Well ok, for signature checking, there's a fairly obvious rationale commented in the code long long ago: /** @todo Implement disable/enable/warn/error/anal policy. */ I just tend to think this is something that should be implemented in rpm core rather than plugins, but maybe you have a case that I fail to see. Some hooks inside FSM are obviously going to be needed for the security labeling (for selinux as well), but the idea of exposing *anything* about of the existence (not to mention internals of it) of the FSM beast to plugins makes me cringe, to put it mildly. I'd expect the needs of security labeling to get by with far less information than passing a pointer to the entire fsm - we'll need to take a closer look at what's really needed there and limit the exposure of what's really rpm's deepest internal guts (and gory :) SECURITYHOOK_SCRIPT_EXEC_FUNC is fairly obvious to me too (selinux would also want 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. As for the patch itself, before considering inclusion the unrelated stuff (reindenting pieces in rpmfc, redundant NULL-pointer checks on free etc) need to be pruned. But that's largely besides the point as you only posted this as a basis of discussion... - Panu -
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint