Closed Ziris85 closed 4 months ago
@Ziris85 hey, the Ubuntu AppArmor is quite heavily patched to support snaps. I expect there's something incompatible between libapparmor in the snap and the Debian kernel AppArmor implementation.
Looking into dmesg
might shed a light.
Either way, we have the --authorize-without-apparmor
option for this case:
https://mir-server.io/docs/ubuntu-frame-configuration-options#heading--snap-configuration-config
Issue is the same as the other one, however, in that the osk snap isn't working properly
This does sound like it is differences in AppAmor between Ubuntu and Debian. We would need to understand what has changed and likely change the Frame snap to fix.
There are, however, a couple of things you can try as a workaround before that happens:
authorise-without-apparmor=true
to the Frame configuration. I'm not sure this will work with "Protocol not available", but worth a try. Or, if this doesn't work:add-wayland-extensions=zwlr_layer_shell_v1:zwp_virtual_keyboard_manager_v1:zwp_text_input_manager_v3
to the Frame configuration.More details on configuring Frame here, or the TL;DR:
snap set ubuntu-frame config "
authorise-without-apparmor=true
"
Hey there @Saviq @AlanGriffiths , thanks for getting back with me! I tried the authorise-without-apparmor=true
, and that had no effect on either the log output complaints or the behavior. I next tried the add-wayland-extensions=zwlr_layer_shell_v1:zwp_virtual_keyboard_manager_v1:zwp_text_input_manager_v3
config, and this seems like it's on the right track? The OSK service starts now, but it's not working as intended - all that happens is a persistent, empty gradient box on the display (no keyboard), and clicking into text fields doesn't produce a keyboard. if I snap restart ubuntu-frame-osk
, it toggles between the empty gradient box and nothing displayed at all heh. I am, however, getting a new warning showing up that wasn't before, each time I restart the OSK, in addition to the flurry of apparmor complaints:
2024-02-09T19:41:37-05:00 ubuntu-frame.daemon[11048]: [2024-02-09 19:41:37.920820] <information> frame: aa_getpeercon() failed for process 14206: Protocol not available
2024-02-09T19:41:38-05:00 ubuntu-frame.daemon[11048]: [2024-02-09 19:41:38.133358] < -warning- > mirserver: Ignoring layer shell protocol violation: wl_surface destroyed before associated zwlr_layer_surface_v1@26
2024-02-09T19:41:38-05:00 ubuntu-frame.daemon[11048]: [2024-02-09 19:41:38.257292] <information> frame: aa_getpeercon() failed for process 11258: Protocol not available
I'm not sure if this is related to the OSK still not showing up or not?
@Ziris85 thanks for the update.
Part of the problem you describe now ("all that happens is a persistent, empty gradient box on the display (no keyboard)" sounds similar to https://github.com/canonical/ubuntu-frame-osk/issues/58. Could you try the version of Ubuntu Frame that's now in testing?
snap refresh ubuntu-frame --candidate
(I think the fix for https://github.com/canonical/ubuntu-frame-osk/issues/58 is already in 2.15, but want to be sure.)
The other part of the problem "clicking into text fields doesn't produce a keyboard" could be a problem with the client app (that needs to request the keyboard when you click on the text field). What app are you testing with?
I've reproduced this and looking from snapd perspective.
With the help of strace I got this:
9500 socketpair(AF_UNIX, SOCK_STREAM, 0, [25, 26]) = 0
9500 getsockopt(25, SOL_SOCKET, SO_PEERSEC, 0x55d07b029af0, [128]) = -1 ENOPROT
I had a look at what the kernel in Debian bookworm (11) says. At the time of this writing this is 6.1.0-17:
This toy C program:
#include <stdio.h>
#include <stdlib.h>
#include <sys/socket.h>
int main(int argc, char **argv) {
int sv[2];
if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) < 0) {
perror("socketpair");
};
char sec_buf[128];
socklen_t sec_buf_len = sizeof(sec_buf);
if (getsockopt(sv[0], SOL_SOCKET, SO_PEERSEC, sec_buf, &sec_buf_len) < 0) {
perror("getsockopt SOL_SOCKET SO_PEERSEC");
}
return 0;
}
Fails as follows:
$ ./a.out
getsockopt SOL_SOCKET SO_PEERSEC: Protocol not available
Similarly strace shows:
socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
getsockopt(3, SOL_SOCKET, SO_PEERSEC, 0x7ffe8a2c7b60, [128]) = -1 ENOPROTOOPT (Protocol not available)
As such I don't believe this particular failure is related to snap sandbox. It seems that it is just not implemented in that particular kernel, yet. As a quick sanity check, the program works fine on Fedora 39 with 6.7.7.
Looking at the kernel some more, in 6.1 this is the implementation:
int security_socket_getpeersec_stream(struct socket *sock, char __user *optval,
int __user *optlen, unsigned len)
{
return call_int_hook(socket_getpeersec_stream, -ENOPROTOOPT, sock,
optval, optlen, len);
}
So I suspect that unless there's an LSM hook present, the error is really ENOPROTOOPT
. Given the extensive patches for AF_UNIX security features that are in Ubuntu kernel, I think this is really the cause.
EDIT: correction, I think there's something I'm missing here, the hook is present in 6.1:
static int apparmor_socket_getpeersec_stream(struct socket *sock,
char __user *optval,
int __user *optlen,
unsigned int len)
{
char *name;
int slen, error = 0;
struct aa_label *label;
struct aa_label *peer;
label = begin_current_label_crit_section();
peer = sk_peer_label(sock->sk);
if (IS_ERR(peer)) {
error = PTR_ERR(peer);
goto done;
}
slen = aa_label_asxprint(&name, labels_ns(label), peer,
FLAG_SHOW_MODE | FLAG_VIEW_SUBNS |
FLAG_HIDDEN_UNCONFINED, GFP_KERNEL);
/* don't include terminating \0 in slen, it breaks some apps */
if (slen < 0) {
error = -ENOMEM;
} else {
if (slen > len) {
error = -ERANGE;
} else if (copy_to_user(optval, name, slen)) {
error = -EFAULT;
goto out;
}
if (put_user(slen, optlen))
error = -EFAULT;
out:
kfree(name);
}
done:
end_current_label_crit_section(label);
return error;
}
The helper is:
static struct aa_label *sk_peer_label(struct sock *sk)
{
struct aa_sk_ctx *ctx = SK_CTX(sk);
if (ctx->peer)
return ctx->peer;
return ERR_PTR(-ENOPROTOOPT);
}
Still digging some more, I switched the snap.ubuntu-frame.ubuntu-frame
profile to complain
mode and ran some more tests to avoid the case of unconfined processes observing something else:
$ aa-exec -p snap.ubuntu-frame.ubuntu-frame cat /proc/self/attr/apparmor/current
snap.ubuntu-frame.ubuntu-frame (complain)
$ aa-exec -p snap.ubuntu-frame.ubuntu-frame ./a.out
getsockopt SOL_SOCKET SO_PEERSEC: Protocol not available
I've suspended debugging as there's something more important I'm looking at. I cannot yet say if this is a kernel bug in Debian or just something that ought to be handled in the app.
From a practical perspective, we can encounter this ENOPROTOOPT
error on non-Ubuntu distros. We should probably treat it in the same way as EINVAL
and enable use of the authorise-without-apparmor
option.
@Ziris85, there's a build with a potential workaround that could try with:
snap install --channel=edge/pr175 ubuntu-frame
snap set ubuntu-frame config "
authorise-without-apparmor=true
"
(Or refresh
if already installed)
It will be sometime next week before I have time to test for myself.
Hmm, what's the easiest way to test this? I have an LXC instance of debian/buster, but that doesn't replicate the problem (as I might have expected if I thought about it).
Hmm, what's the easiest way to test this? I have an LXC instance of debian/buster, but that doesn't replicate the problem (as I might have expected if I thought about it).
--vm
to lxc launch
should do?
--vm
tolxc launch
should do?
Sounds plausible, but that doesn't reproduce either.
OK, reproduced on bare metal. But the fix doesn't seem to work as expected. More tomorrow!
OK, reproduced on bare metal. But the fix doesn't seem to work as expected. More tomorrow!
Testing the right thing does work though. :tada:
Hi!
@AlanGriffiths im not 100% sure what the fix to the issue is now. Did you find one and could you guide me to the correct settings?
Thanks tbanetwork
@tbanetwork sorry if it wasn't clear: adding authorise-without-apparmor=true
to the config
option (as described above) now works with Debian's version of AppArmor.
@AlanGriffiths thanks for getting back to me and pointing me in the right direction.
Hello! To begin with, I think this issue might be closely related to #77 , though in my case I'm running the latest version of Debian with apparmor in full enforcing mode, and I'm seeing a very similar, though slightly different, error:
Issue is the same as the other one, however, in that the osk snap isn't working properly. The frame (I'm using
wpe-webkit-mir-kiosk
here too) is otherwise working fine, as far as I can tell. I also installed using the pretty simple steps for ubuntu-frame and ubuntu-frame-osk. Versions at play on my system:Any more info I can provide to help debug this, let me know! Thanks!