On 12/20/2016 6:40 AM, José Bollo wrote: > Le lundi 19 décembre 2016 à 13:25 -0800, Casey Schaufler a écrit : > > snip >> A brief look at the existing modules leads me to believe that >> everyone ought to be happier if we moved the LSM task blob out >> of the cred structure. SELinux keeps a small (6xu32) task blob >> that has no reason to share and refcount. Smack has a couple of >> lists in the task blob that really shouldn't be in the cred. >> There would have to be some rework of the task_alloc and task_free >> hooks to get the life of the blobs correct, but I think on the >> whole it would be lots cleaner. >> > Hi Casey, > > Let suppose that creds is, in effect, the wrong place for implementing > PTAGS and let suppose that the correct way is to add a t_ptags element > in the task structure. > > How to use task_alloc and task_free? There is nothing there. Is it just > possible to inherit or copy the parent attributes? no. > > So there is a need to define a hook to copy or do something for the > child based on the parent. A new hook, a kind of 'task_child_init' > whose argument would be the task to init. > > Is it it? > > Best regards > José Bollo My suggestion at this point is that we introduce a "t_security" field to task_struct (in include/linux/sched.h) under #CONFIG_SECURITY. There is already a task_free hook that should suffice, but the existing task_create hook will either need to be changed to get passed the task_struct or supplemented with a task_alloc hook. A copy_task hook may prove necessary, but we'll have to look into that. Security module data that belongs associated with the task needs to get moved, but that can be done by the module maintainers. It doesn't sound like there would be resistance to this from the security side of the house, but it needs to get run past the task management maintainers. A patch set, used by an existing module would be the best approach for that. I do not think that Smack is a good example as it is the one module that would probably be best served by having some data in both places. _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
