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
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
