Comment 5 for bug 2063976

Revision history for this message
John Johansen (jjohansen) wrote :

> To clarify, this is not something that can be solved upstream in apparmor, and a profile can't be accepted due to the nature of the path location?

correct, if it is a unprivileged user writable location it can't be fixed entirely upstream. It is possible for us to ship a profile that is disabled in some way but that takes a privileged user action to enable. Eg. we could ship a profile using the xattrs attachment from above, then the user would be responsible for setting the xattr with setfattr.

packaging nsjail is an option for Ubuntu but like you said it wouldn't directly address previous versions and AOSP probably wouldn't like it. With that said this isn't going to be an Ubuntu only restriction, the security community in general is looking at different ways of restricting unprivileged user namespaces. SElinux has picked up some ability to mediate them, but isn't really applying it in policy yet. The OSS email list (<email address hidden>) has been discussing other options as well. The number of exploit chains associated with them has forced us to start locking them down. The AppArmor solution will be available to other distros as well, it already available upstream in the kernel and apparmor 4.0.

AppArmor side there is work on aa-notify that we are looking at SRUing. That will help desktop users if they have it installed. Where they can get a notification that will take them to a simple gui that will allow them to click enable (with a password) instead of having to know the details underneath. It won't be integrated into the security center or pretty. But a little better than the current situation for the user.