[Dev] Gumd and security-manager integration

Stéphane Desneux stephane.desneux at open.eurogiciel.org
Tue Oct 14 21:55:01 GMT 2014


My 2 cents:

* the idea to use hooks to initialize user databases (migration of app
fw to multiuser) has already been reviewed some months ago and the
conclusion was already there: no hooks. Does the position of gumd
"inside" the security-manager changes this conclusion ? Is it worth
evaluating this solution again ?

* having a kind of "sanity" service at startup could be a way to
cleanup/adjust what needs to be after each reboot. For example, for user
deletion, it's easy to create a kind of transaction to execute all
operations, assuming we can't rollback in the middle: we first write in
a temp file the "intent to delete" a user, sync fs, then finally delete
this file when the user is correctly deleted. So at startup, it's easy
to check the existence of the file and do what's needed to complete the
deletion. No file=no op=no impact on boot time. The same could apply to
smack labels on some strategic objects: restoring the correct labels and
emitting a warning is quite easy.

BR
-- 
Stéphane Desneux
Intel OTC - Vannes/FR
gpg:1CA35726/DFA9B0232EF80493AF2891FA24E3A2841CA35726

On 14/10/2014 15:13, Zaman, Imran wrote:
> Hi
> 
> We had a conference call today and agreed on the items below:
> 
> AP 1a: Rafal (and his team) will investigate hooks-based approach and if it is simple and covers the uses cases, then we will go with it.
> AP 1b: If Rafal concludes that the 'hook-based' approach is not the way to go, then libgum will be integrated to security-manager directly (no more discussion needed on it)
> AP 2: Rafal (and his team) will try out 'libgum/gumd with 'P2P dbus' at image creation time; in case of any issues imran/Jussi needs to be contacted to resolve the issues
> AP 3: Imran will look into error handling of the scripts once Rafal (and his team) concludes which approach to take as per AP 1.
> AP 4: Rafal will list down the changes needed at libgum/gumd level and will notify imran/jussi to implement those changes along with the timeline.
> 
> Rafal, please feel free to contact me and/or jussi if you have any concerns/issues regarding libgum and gumd.
> We are open to changes to libgum/gumd that can expedite in solving the problem(s) :-)
> 
> BR
> imran
> ________________________________________
> From: Dev [dev-bounces at lists.tizen.org] on behalf of Zaman, Imran [imran.zaman at intel.com]
> Sent: 13 October 2014 14:00
> To: Jussi Laako; Rafał Krypa
> Cc: dev at lists.tizen.org
> Subject: Re: [Dev] Gumd and security-manager integration
> 
> xattr/smack label handling in gumd at: https://github.com/01org/gumd/blob/master/src/common/gum-file.c#L116
> 
> Currrently all the xattr is copied from /etc/skel; please see the above code..
> 
> smack label is read from the config file for tizen: https://github.com/01org/gumd/blob/master/dists/rpm/tizen/packaging/gumd-tizen.conf#L116
> 
> Lets talk more about it tomorrow.
> 
> BR
> imran
> 
> ________________________________________
> From: Dev [dev-bounces at lists.tizen.org] on behalf of Jussi Laako [jussi.laako at linux.intel.com]
> Sent: 13 October 2014 12:19
> To: Rafał Krypa
> Cc: dev at lists.tizen.org
> Subject: Re: [Dev] Gumd and security-manager integration
> 
> On 10.10.2014 20:03, Rafał Krypa wrote:
>> 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.
> 
> We can do that, but I'd propose to at least run all the removal still,
> even despite of an error, because it would minimize amount of potential
> left-overs. We could then leave the UID in place, but disable logins for
> that user?
> 
>> I don't suggest doing rollbacks. IMHO partially removed user that cannot be used anymore is acceptable.
> 
> At least for user creation stage it would be nice to have possibility to
> rollback. But those would require having an LFS filesystem, which I
> think we should have in first place at least for IVI and such. It would
> also allow doing quick and complete factory-defaults reset.
> 
>> 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?
> 
> Imran can probably quicker point the place where it happens. It's "User"
> something. We added the code, because by default home directory was
> inheriting "System" label or something like that and it prevented user
> logins...
> 
>> Are you saying that /etc/skel handling in gumd prevents security xattrs? That would be perfect, we could simply set the proper labels there.
> 
> Intention is to copy things exactly over from there, including xattrs,
> only change naturally being UID/GID change for the items. So if it is
> possible to set correct attributes there, it would be really nice. Only
> case where I see that being not straightforward is case when you'd like
> to create some user-specific labels that no other user has. But these
> could be handled with the post-creation script.
> 
>> 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.
> 
> It needs to be, but now there's environment variable to switch it to use
> a regular socket for dbus communication instead of system bus daemon. So
> you could start gumd with "gumd &" and then run the gum-utils without
> need for other services like system-bus daemon. Once you are done, you
> could "killall gumd".
> 
>> But this approach is likely require some changes to gumd. At least cynara support andhandling error codes from scripts.
> 
> That shouldn't be an issue. We'll modify script handling and see into
> adding Cynara support.
> 
> 
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev
> ---------------------------------------------------------------------
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki
> Business Identity Code: 0357606 - 4
> Domiciled in Helsinki
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev
> ---------------------------------------------------------------------
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki 
> Business Identity Code: 0357606 - 4 
> Domiciled in Helsinki 
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev
> 


More information about the Dev mailing list