On Wed, Sep 15, 2021 at 2:27 AM Josh Gao <jmgao@xxxxxx> wrote: > > On Tue, 2021-09-14 at 10:38 -0400, Stephen Smalley wrote: > > Currently in the case of SELinux those attribute values are stored in > > the cred security blob, which > > used to be the task security blob (hence the legacy > > task_security_struct name) before creds existed. > > Later LSM revived support for a separate task security blob for the > > sake of TOMOYO so that does exist > > if needed but SELinux doesn't currently allocate or use it. AppArmor > > switched to using it for its task-specific > > state after it was restored; SELinux could split its current > > task_security_struct into two parts (per-cred and > > per-task) and do likewise if that is worthwhile (not sure). > > My understanding is that `struct cred` is a per-task attribute, not > per-thread-group, so different threads can have different task security > blobs. Do you know if this is possible without doing something weird > like setuid in a multithreaded process? You can't just set the audit signal once in the first thread before creating multiple threads and let the child threads inherit it across clone(2)? Currently ->exit_signal and ->pdeath_signal are part of task_struct, so it seems consistent to put this into something per-task, whether part of task->security or task->cred->security. If not and it needs to be shared across a thread group, I guess you could try to get a new security field added to the appropriate structure instead.