On gio, 2014-01-09 at 17:57 +0000, Schaufler, Casey wrote: > > -----Original Message----- > > From: dev-boun...@lists.tizen.org [mailto:dev-boun...@lists.tizen.org] On > > Behalf Of José Bollo > > Sent: Thursday, January 09, 2014 8:36 AM > > To: dev@lists.tizen.org > > Subject: [Dev] pam module for Smack > > > > Hi, > > > > We are facing problems with the commands 'su' and 'ssh' that don't set the > > user Smack context. Such a service would naturally be accomplished by PAM > > the pluggable authentication module that is integrated with well known > > commands: 'login', 'su', 'ssh' and by other less known as Gnome session > > manager or weston. > > > > Currently, the context is set by systemd. I would like to know if there is a > > reason that explains that systemd doesn't use login+pam to achieve that > > behaviour? > > The reason is that systemd (currently) creates the user session without a > login process. Going forward that does have to change. The user session is > started in the "User" domain. This results in all of the processes spawned in > the user session to be in the "User" domain. That's very clean. > > > I'm thinking that a pam_smack module would be the most integrated way of > > doing the thing. Why would it be wrong to think that? Ideas? > > A pam_smack module would be a fine thing, and has been on the Smack todo list > since 2008. > > > I've looked at what have to be done for making a pam_smack module and it > > make me believe that it is really easy to achieve. > > Excellent! I would be delighted to see details on how you'd like to handle > determining what Smack label to assign the session. I had envisioned a > /etc/smack/users file that lists what labels a user can use and which is used > if none is specified. You could also base it on the label of the user's home > directory.
I have made a PAM module for smack and we are experimenting it here. The policy is: root -> System, not root -> User. It applies on the running context and on the attached tty (what is really important). It is a very simple policy that can be amended and changed. But keeping it simple is really pleasing to me. Comments very welcome.... Best regards José _______________________________________________ Dev mailing list Dev@lists.tizen.org https://lists.tizen.org/listinfo/dev