On 2014-10-10 15:45, Jussi Laako wrote: > On 10.10.2014 16:03, Rafał Krypa wrote: >> * hooks mechanism needs to be enhanced: do post- and pre- hooks, >> check error codes from scripts > > Pre-user-creation and post-user-delete are kind of pointless, because in > pre-creation-state you don't yet have UID or anything else for the user, just > username. And in post-user-delete these don't exist anymore.
You are right. The only reason I mentioned this resulted from my misunderstanding of gumd code. I thought that it only does post-creation and post-removal. > > We can check error codes, but what would we do when there's an error? Then the user removal should stop and return an error. If we are lucky, the user removal action will be retried and will work then. If not, the user would stay in half-deleted state. From my point of view it's important to prevent reuse of uid for a user that still has some security policy configuration. The same should work for home directory - it's unsafe to let the new user access left over files from an old user that couldn't be properly removed. > If we would have filesystem that supports snapshots, we could roll back > safely. I don't suggest doing rollbacks. IMHO partially removed user that cannot be used anymore is acceptable. > >> 1. Access control >> * Check whether the user is privileged to perform configuration on >> other users > > We can make group-based access control on this, I'd propose using standard > "wheel" group for the purpose. Current consensus for user profiles on Tizen is to have them defined as set of privileges granted for the user. These privileges will be enforced by Cynara in most cases. This way also has an extra benefit of easy run-time configuration - privileges can be granted or revoked for users. Having a user management privilege controlled by DAC group is doable but complicates things. I'd like to vote for doing it with Cynara, if possible. > >> * We've got Cynara for such checks, integration scenarios #1 and >> #2 require gumd to integrate with Cynara > > Is it already available and working? Cynara itself it's available. Means for granting privileges for users is not yet implemented, but should be in 1-2 months. >> 2. Smack setup >> * When a user is created, files in the new home directory needs >> proper Smack labels > > This is already done by gumd. It wouldn't have been possible to integrate and > verify gumd on Tizen without it. That's fine, it's one way to do that. Could you point me to the place where it is handled? What label are you giving to the home directory? > But you should figure out how to do this correctly with respect to /etc/skel > as it works already for normal unix DAC permission mask... Are you saying that /etc/skel handling in gumd prevents security xattrs? That would be perfect, we could simply set the proper labels there. >> * 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 > > These are suitable for a pre-remove script. > >> * 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? > > We added support for running the daemon in p2p dbus mode through environment > variable, so you don't need to have dbus-daemon running. This should be > enough... Does gumd daemon still need to be running for gum-utils to work? If yes, is your solution usable when image is created by mic? I'm only asking, it would be great to have gum-utils or libgum usable at image creation time. We wouldn't have to care about using bare useradd commands and fixing everything else it doesn't handle. >> 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. > > I think best is to use post-creation script for this purpose. But I can live > with this approach too as long as it doesn't require Tizen specific changes > to gumd... And I can live with the scipt-level integration. :) But this approach is likely require some changes to gumd. At least cynara support andhandling error codes from scripts. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
