[03:26] amurray: Great podcast last week; I'm really looking forward to the security prompter thing being stable. Is there any particular reason why it has to be limited to snaps? [04:07] blahdeblah: currently the implementation in prompting-client is quite snap specific and it would need a bunch of work to make it applicable to general applications - but the AppArmor prompting feature itself in the kernel is generic, and supports multiple prompt listeners [04:08] so it is possible to write a separate client that deals with non-snap applications via prompting [04:12] But no plans for that at the moment, I take it? [07:50] blahdeblah: not that I know of unfortunately - but I will raise it internally and let you know if we can get any buy-in [07:51] amurray: <3 [07:57] Does the prompter work in the terminal for command line snaps? [10:13] mcphail: no - and I am wondering how that might possibly work.. I guess if the shell itself was somehow tied in to listen for prompts it could do that but otherwise given a terminal only has a single input I think this would be a pretty challenging UX [11:52] amurray: I suppose I was thinking of something like how apt uses `dialog`, which degrades to a TUI if there's no graphical interface. But that would probably require all snaps to run in another wrapper layer, I'd guess? [19:28] hi apparmor experts, [19:28] what is the operation being attempted that is triggering this log? [19:28] [Tue Sep 10 19:25:27 2024] audit: type=1400 audit(1725996325.250:4072): apparmor="ALLOWED" operation="capable" class="cap" namespace="root//lxd-x-uat-apparmor_" profile="ubuntu_pro_apt_news" pid=314582 comm="python3" capability=5 capname="kill" [19:28] i.e., what is the call? [19:28] "capable" [19:28] I'm trying to find out where in the code this is happening [19:29] CAP_KILL (from capability=5 capname="kill") [19:29] how would I see this in strace, for example? [19:30] unfortunately several syscalls can do several capability checks so it's hard to pinpoint exactly [19:30] but I assume a syscall would return -EACCESS in strace [19:30] problem is how to run strace on a confined app :)) [19:31] this is somewhere inside apt, [19:31] -EACCES better yet [19:31] Maybe use some kind of systemwide BPF tool instead? (I think it'd exist but I don't know of any names unfortunately) [19:31] https://manpages.ubuntu.com/manpages/oracular/man7/capabilities.7.html CAP_KILL: Bypass permission checks for sending signals (see kill(2)). This includes use of the ioctl(2) KDSIGACCEPT operation. [19:31] it was told to download a file to a directory, and for some reason when that directory is non-root owned, that capability is checked [19:31] oh, and this is xenial [19:33] * ahasenack continues [20:25] was xenial where apt tried to split apart downloads into a separate unprivileged _apt user account? [20:31] I don't know where it started, but that's the current behavior [20:32] but yeah, it's because of this split [20:32] I'm still not entirely sure why the capability check isn't denied when the https process (what actually downloads the thing) is running as root [20:32] it's indeed sending a SIGINT signal [20:33] 23642 kill(23645, SIGINT [20:33] 23645 <... select resumed> ) = 1 (in [0]) [20:33] 23642 <... kill resumed> ) = -1 EPERM (Operation not permitted) [20:33] everything is under the same apparmor profile [20:33] python via libapt spawned apt's https download process, which detected it could switch to the _apt user (because the target directory is owned by _apt) [20:34] and at some point the INT signal is sent (I think at the end of the download: I traced this signal() to a worked destructor in the c++ code) [20:35] the profile isn't allowing the kill capability, but as root that worked [20:35] now I know better what's going on, and that's enough for today [20:36] I don't know where it started, but that's the current behavior [20:36] and also the behavior in xenial, to be clear