[Rpm-maint] Tizen rpm security plug-in interface
Reshetova, Elena
elena.reshetova at intel.com
Tue Nov 1 10:52:15 UTC 2011
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: security.patch
Type: application/octet-stream
Size: 170022 bytes
Desc: not available
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20111101/4b78779b/attachment-0001.obj>
-------------- 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/20111101/4b78779b/attachment-0001.p7s>
More information about the Rpm-maint
mailing list