Re: [Kernel-packages] [Bug 1990064] Re: unconfined profile denies userns_create for chromium based processes
> Previously we only had the option of using a system wide sysctl > kernel.unprivileged_userns_clone to disable unprivileged user > namespaces. Debian defaults this to off, and you have to opt in. Just to avoid misunderstandings (I failed to parse the above sentence unambiguously): in Debian, unprivileged user namespaces have been enabled by default since Bullseye. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1990064 Title: unconfined profile denies userns_create for chromium based processes Status in apparmor package in Ubuntu: Confirmed Status in linux package in Ubuntu: Incomplete Bug description: For Ubuntu 22.10, since the last kernel update, i can´t launch any chromium based browser, due to apparmor denying userns_create dmesg shows: apparmor="DENIED" operation="userns_create" class="namespace" info="User namespace creation restricted" error=-13 profile="unconfined" pid=21323 comm="steamwebhelper" requested="userns_create" denied="userns_create" This happens for every process which uses a chromium engine, like google chrome itself or in this case steamwebhelper. Might be related to this change?: https://patchwork.kernel.org/project/netdevbpf/patch/20220801180146.1157914-5-f...@cloudflare.com/ not sure if it got merged in this form though.. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1990064/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1379535] Re: policy namespace stacking
I see this is "Fix Released" everywhere but on the upstream AppArmor project. I understand this has made its way upstream and works with mainline kernel, e.g. for LXC. If my understanding is incorrect, please clarify what's left to do here (or perhaps track it on a finer-grained follow-up bug :) ** Changed in: apparmor Status: In Progress => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1379535 Title: policy namespace stacking Status in AppArmor: Fix Released Status in apparmor package in Ubuntu: Fix Released Status in linux package in Ubuntu: Fix Released Status in apparmor source package in Xenial: Fix Released Status in linux source package in Xenial: Fix Released Bug description: Tracking bug for supporting stacked policy namesapaces (ie, different profiles on host, container, container in a container, etc) To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1379535/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1384746] Re: Support multiple versions of AppArmor policy cache files
It seems to me this was fixed & released a while ago. https://bugs.launchpad.net/apparmor/+bug/1384746/comments/2 could be tracked on a new, follow-up bug, if still desired. ** Changed in: apparmor Status: In Progress => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1384746 Title: Support multiple versions of AppArmor policy cache files Status in AppArmor: Fix Released Status in apparmor package in Ubuntu: Triaged Status in linux package in Ubuntu: Triaged Bug description: The AppArmor parser should support multiple directories of policy cache files. Directories should be specific to a certain AppArmor kernel feature set. From a distro standpoint, this would allow policy caches to be created during kernel install/upgrade. To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1384746/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1117804] Re: ausearch doesn't show AppArmor denial messages
Meta: I've re-read the discussion from December 2017. If there were messages later than this on the thread, I missed them due to suboptimal mailing list archive presentation. Sorry if this leads me to wrong conclusions! I lack the skills to do the actual work I think should be done. The only way I can help here is by facilitating the conversation, so I'll do that: I'd like to make sure there's no misunderstanding about the various opinions that were expressed, the current state of the discussion, and what the next steps should be (e.g. who's waiting for whom). My understanding is that [my personal opinion in square brackets]: 0. Upstream acknowledges that there is a problem and that it would be nice to solve it. 1. There's indeed desire upstream for finding a good balance between sharing (via generic infrastructure and possibly message types) and taking into account that each LSM has different needs. [This makes sense to me: there are probably bits worth sharing instead of every LSM doing their own thing 100% in their dark corner. Now, obviously finding a good balance requires discussion between LSMs to identify what can be shared and what is specific to each, which has its costs (and may require different skills than writing kernel code).] 2. There's a consensus about the fact we need _some_ way to tell which LSM has sent the message. Several options have been mentioned, including adding a new lsm= identifier and using different allocated blocks (be it in the 1400 range or elsewhere). [I'm glad that the door remains open for the option we had in mind initially.] 3. The ball is in our court: upstream proposed several options and I don't see them reach actionable conclusions without our input. At this point, it seems that the next step is: AppArmor developers express their needs. For example: * Are there existing messages formats supported by the auditd suite that would work for us and we'd be happy to share with other LSMs? If yes, great: if we start using them our users will benefit from it without having to adapt existing tools. * What are our needs that we think are specific to AppArmor? (It might be that once we state them, another LSM developer will say "actually, this could be useful for us too", who knows :) * Once we have the answers to the above questions, we can start checking many AppArmor-specific identifiers we need today and how many extra spare ones we want allocated. (Without this info, nobody can decide whether we can fit in the 1400 range.) John, are we on the same page? If not, I'd love to know what we understood differently :) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1117804 Title: ausearch doesn't show AppArmor denial messages Status in AppArmor: Confirmed Status in audit package in Ubuntu: Confirmed Status in linux package in Ubuntu: Incomplete Bug description: The following command should display all AVC denials: ausearch -m avc However, it doesn't work with AppArmor denials. Here's a quick test case to generate a denial, search for it with ausearch, and see that no messages are displayed: $ aa-exec -p /usr/sbin/tcpdump cat /proc/self/attr/current cat: /proc/self/attr/current: Permission denied $ sudo ausearch -m avc -c cat ausearch claims that there are no matches, but there's a matching audit message if you look in audit.log: type=AVC msg=audit(1360193426.539:64): apparmor="DENIED" operation="open" parent=8253 profile="/usr/sbin/tcpdump" name="/proc/8485/attr/current" pid=8485 comm="cat" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1117804/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1117804] Re: ausearch doesn't show AppArmor denial messages
FTR this was raised as a potential blocker for enabling AppArmor by default on Debian: https://bugs.debian.org/872726. I'm going to investigate why this is a blocker there. tl;dr: as the audit maintainers said in 2014 (https://www.redhat.com/archives/linux-audit/2014-May/msg00119.html) and 2016 (https://www.redhat.com/archives/linux- audit/2016-April/msg00129.html), we should use events ids from the range that has been allocated to us (1500-1599) instead of from the range assigned to SELinux. Any plans / ETA to fix this? Regardless of how you would prioritize this problem otherwise, the fact it might prevent AppArmor from being enabled by default in Debian could be a reason to handle it ASAP :) ** Bug watch added: Debian Bug tracker #872726 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872726 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1117804 Title: ausearch doesn't show AppArmor denial messages Status in AppArmor: Confirmed Status in audit package in Ubuntu: Confirmed Status in linux package in Ubuntu: Incomplete Bug description: The following command should display all AVC denials: ausearch -m avc However, it doesn't work with AppArmor denials. Here's a quick test case to generate a denial, search for it with ausearch, and see that no messages are displayed: $ aa-exec -p /usr/sbin/tcpdump cat /proc/self/attr/current cat: /proc/self/attr/current: Permission denied $ sudo ausearch -m avc -c cat ausearch claims that there are no matches, but there's a matching audit message if you look in audit.log: type=AVC msg=audit(1360193426.539:64): apparmor="DENIED" operation="open" parent=8253 profile="/usr/sbin/tcpdump" name="/proc/8485/attr/current" pid=8485 comm="cat" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1117804/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1408106] Re: attach_disconnected not sufficient for overlayfs
Hi! What kind of (realistic) timeline can we expect here? (With the move
to ZFS for containers, I wonder :)
E.g. is this part of your goals for 16.10? (I mean: for the AppArmor
/Ubuntu-specific parts, as I've learnt to be patient wrt. the
upstreaming to Linux mainline.)
Thanks for your work on AppArmor!
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1408106
Title:
attach_disconnected not sufficient for overlayfs
Status in AppArmor:
In Progress
Status in apparmor package in Ubuntu:
Confirmed
Status in linux package in Ubuntu:
Triaged
Bug description:
With the following use of overlayfs, we get a disconnected path:
$ cat ./profile
#include
profile foo {
#include
capability sys_admin,
capability sys_chroot,
mount,
pivot_root,
}
$ cat ./overlay.c
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char* argv[]) {
int i = 0;
int len = 0;
int ret = 0;
char* options;
if (geteuid())
unshare(CLONE_NEWUSER);
unshare(CLONE_NEWNS);
for (i = 1; i < argc; i++) {
if (i == 1) {
len = strlen(argv[i]) + strlen("upperdir=,lowerdir=/") + 2;
options = alloca(len);
ret = snprintf(options, len, "upperdir=%s,lowerdir=/", argv[i]);
}
else {
len = strlen(argv[i]) + strlen("upperdir=,lowerdir=/mnt") + 2;
options = alloca(len);
ret = snprintf(options, len, "upperdir=%s,lowerdir=/mnt",
argv[i]);
}
mount("overlayfs", "/mnt", "overlayfs", MS_MGC_VAL, options);
}
chdir("/mnt");
pivot_root(".", ".");
chroot(".");
chdir("/");
execl("/bin/bash", "/bin/bash", NULL);
}
$ sudo apparmor_parser -r ./profile && aa-exec -p foo -- ./a.out /tmp
[255]
...
Dec 12 14:31:38 localhost kernel: [57278.040216] audit: type=1400
audit(1418387498.613:712): apparmor="DENIED" operation="exec" info="Failed name
lookup - disconnected path" error=-13 profile="foo" name="/bin/bash" pid=18255
comm="a.out" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
With the above, the expectation was for the denial to be /mnt/bin/bash. There
are three ways forward:
1. the correct solution is to patch overlayfs to properly track the loopback,
but this will take a while, may ultimately be unachievable. UPDATE: upstream is
currently working on this and Ubuntu will engage with them
2. we could rely on the fact that overlayfs creates a private unshared
submount, and provide a way to not mediate the path when that is present, and
tagged. This would take a bit of time, and might be the preferred method over 1
longer term
3. we could extend attach_disconnected so that we can define the attach root.
Eg, we can use profile foo (attach_disconnected=/mnt) {} such that '/bin/bash'
maps to '/mnt/bin/bash'. UPDATE: THIS IS NOT VIABLE
To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1408106/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
