[16:35] ahasenack: hrm, I wonder if a specialized tool for that might make sense. aa-unconfined was originally intended as a "audit my system for things to consider confining" type tool. [16:54] sbeattie: I think it does, look at what I did to check if a process was confined [16:54] sbeattie: https://pastebin.ubuntu.com/p/Z4g8c36ZWM/ [16:54] and I understand there is a case where this isn't enough, when there are no (or there are) stacking lsm modules [16:56] yeah, the potential cases / logic are more complex than 15 years ago when it was just "look in /proc/pid/attr/current" and it would be good to capture them in one place. [16:57] * sbeattie forgets if 'ps -Z` does the right thing in the face of stacking; I think it *should* due to IIRC relying on libapparmor, but it would be worth testing. [16:58] ahasenack: please feel free to open a bug somewhere, the gitlab project would be fine. [16:58] ok [17:11] sbeattie: filed: https://gitlab.com/apparmor/apparmor/-/issues/230 [17:11] Issue 230 in apparmor/apparmor "Tool to check confinement status of a process" [Opened] [17:16] ps -Z does not rely on libapparmor and it doesn't do the right thing when stacking [17:16] aa-status should do the right thing [17:30] jjohansen: ah, bummer. [17:32] newer LSM stacking patches add a context file [17:32] /proc//attr/context which provides a compound label with \0 separated fields [17:32] so something like [17:32] apparmor=unconfined\0selinux=unconfined_t\0smack=_ [17:33] which lets applications that are aware of it get all the values in a single read, and have a unified parsing [17:33] so as long as we get patches into ps etc to use context when available they will be able to do the right thing [17:34] but afaik the userspace side of things is still a big todo