On Tue, 2021-09-14 at 10:38 -0400, Stephen Smalley wrote: > We already have a /proc/$PID/attr directory for LSM-related process > attributes. > Simple enough to add a new attribute there if we want it to be > general/applicable to other > LSMs. That interface only allows a task to modify its own attributes > (see proc_pid_attr_write); > I assume that suffices here? Other attributes set that way (e.g. > fscreate / create_sid) are similarly > inherited across fork and unconditionally reset on execve. Thanks, that seems like a good place for it. > 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? > With respect to the implementation, it is generally frowned upon to > embed SELinux-specific fields and code > in the core kernel (versus wrapping in a LSM security field and > hooks) > and I think most if not all of what > you want is achievable through existing security fields and hooks > once > you add a new attribute to /proc/pid/attr. Yeah, I originally implemented this generally for all users of audit, but made it selinux specific after some discussion about how to turn the feature on/off globally. Your suggestion definitely seems like the right way to implement this. Thanks, Josh
