[Rpm-maint] Tizen rpm security plug-in interface
Reshetova, Elena
elena.reshetova at intel.com
Mon May 14 10:37:24 UTC 2012
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-bounces at lists.rpm.org
[mailto:rpm-maint-bounces at lists.rpm.org] On Behalf Of Reshetova, Elena
Sent: Tuesday, November 01, 2011 12:52 PM
To: Panu Matilainen
Cc: rpm-maint at 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:pmatilai at laiskiainen.org]
Sent: Friday, October 28, 2011 12:19 PM
To: Reshetova, Elena
Cc: rpm-maint at 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 -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7220 bytes
Desc: not available
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20120514/c2eda561/attachment-0001.p7s>
More information about the Rpm-maint
mailing list