[Dev] Gumd and security-manager integration

Rafał Krypa r.krypa at samsung.com
Fri Oct 10 13:03:14 GMT 2014


On 2014-10-08 18:08, Dominig ar Foll (Intel OTC) wrote:
> Hello,
>
> listening at the pros and cons, I have to accept that there is no bad solution, nevertheless we need to decide for one solution. For 1 requirement offering 2 modes of operation is 1 too much.
> As someone need to decide, I "propose" to call gumd from the security manager for user creation and removal. Login and Logoff are not concerned and will remain direct call to gumd
>
> @Raphal,
> please sync with Jussi on this mailing list on the best way to encapsulate user creation and provide the right label to the various files and directories.

Hello,
Let's consider our possibiliies and requirements and check what's gonna work best.
Since security-manager is going to be the only entity responsible for configuring Smack and Cynara (and some related DAC stuff too), it has to integrate with gumd somehow.

As I understand, there are three potentially viable ways to do that:

 1. Write security-manager hooks for gumd and put them into /etc/gumd/*.d
      * potentially easiest
      * hooks mechanism needs to be enhanced: do post- and pre- hooks, check error codes from scripts
      * may require some Tizen-specific modifications in gumd code
 2. Let security-manager listen for dbus broadcasts from gumd
      * risk of missing a notification, causing dangerous inconsistency
      * may also require some Tizen-specific modifications in gumd code
 3. Expose user management API in security-manager, make it call gumd
      * chains the two together
      * gumd interface becomes internal to the platform, all user management should go through security-manager
      * doesn't need any changes to gumd to cover all requirements


This is what should be done for user configuration apart from what gumd already does:

 1. Access control
      * Check whether the user is privileged to perform configuration on other users
      * We've got Cynara for such checks, integration scenarios #1 and #2 require gumd to integrate with Cynara
 2. Smack setup
      * When a user is created, files in the new home directory needs proper Smack labels
      * When a user is removed, it may require removal of Smack rules for applications installed by that user
 3. Cynara setup
      * When a user is removed, we must remove all private Cynara rules for that user
 4. Offline mode
      * During image creation, when no deamons run, some users must be pre-created and applications pre-installed
      * Apart from standard user and group creation (calling useradd instead of gumd?) it requires Smack and Cynara setup
      * We already implement an offline, deamon-less version of security-manager to be called by root during image creation. Is gumd going to provide such tool as well?

Taking all of the above into account, I suggest doing the integration scenario #3 - wrap gumd in security-manager. This enables best handling of Cynara and Smack configuration, keeps related logic inside (i.e. what Smack label is assigned to home directory). It also doesn't require and
Tizen-specific changes to gumd, keeping them in security-manager, which is a Tizen-only thing by design.

Jussi, please share your point of view on this matter.

Best regards,
Rafal Krypa

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tizen.org/pipermail/dev/attachments/20141010/d74af51d/attachment.html>


More information about the Dev mailing list