| blahdeblah | 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? | 03:26 |
|---|---|---|
| amurray | 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:07 |
| amurray | so it is possible to write a separate client that deals with non-snap applications via prompting | 04:08 |
| blahdeblah | But no plans for that at the moment, I take it? | 04:12 |
| amurray | 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:50 |
| blahdeblah | amurray: <3 | 07:51 |
| mcphail | Does the prompter work in the terminal for command line snaps? | 07:57 |
| amurray | 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 | 10:13 |
| mcphail | 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? | 11:52 |
| ahasenack | hi apparmor experts, | 19:28 |
| ahasenack | what is the operation being attempted that is triggering this log? | 19:28 |
| ahasenack | [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_<var-snap-lxd-common-lxd>" profile="ubuntu_pro_apt_news" pid=314582 comm="python3" capability=5 capname="kill" | 19:28 |
| ahasenack | i.e., what is the call? | 19:28 |
| ahasenack | "capable" | 19:28 |
| ahasenack | I'm trying to find out where in the code this is happening | 19:28 |
| sbeattie | CAP_KILL (from capability=5 capname="kill") | 19:29 |
| ahasenack | how would I see this in strace, for example? | 19:29 |
| georgiag | unfortunately several syscalls can do several capability checks so it's hard to pinpoint exactly | 19:30 |
| georgiag | but I assume a syscall would return -EACCESS in strace | 19:30 |
| ahasenack | problem is how to run strace on a confined app :)) | 19:30 |
| ahasenack | this is somewhere inside apt, | 19:31 |
| georgiag | -EACCES better yet | 19:31 |
| rlee287 | 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 |
| sbeattie | 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 |
| ahasenack | 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 |
| ahasenack | oh, and this is xenial | 19:31 |
| * ahasenack continues | 19:33 | |
| sbeattie | was xenial where apt tried to split apart downloads into a separate unprivileged _apt user account? | 20:25 |
| ahasenack | I don't know where it started, but that's the current behavior | 20:31 |
| ahasenack | but yeah, it's because of this split | 20:32 |
| ahasenack | 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 |
| ahasenack | it's indeed sending a SIGINT signal | 20:32 |
| ahasenack | 23642 kill(23645, SIGINT <unfinished ...> | 20:33 |
| ahasenack | 23645 <... select resumed> ) = 1 (in [0]) | 20:33 |
| ahasenack | 23642 <... kill resumed> ) = -1 EPERM (Operation not permitted) | 20:33 |
| ahasenack | everything is under the same apparmor profile | 20:33 |
| ahasenack | 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:33 |
| ahasenack | 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:34 |
| ahasenack | the profile isn't allowing the kill capability, but as root that worked | 20:35 |
| ahasenack | now I know better what's going on, and that's enough for today | 20:35 |
| ahasenack | <ahasenack> I don't know where it started, but that's the current behavior | 20:36 |
| ahasenack | and also the behavior in xenial, to be clear | 20:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!