John Johansen wrote: > On 07/03/2018 04:41 PM, [email protected] wrote: > > Hi, > > > > I once reported an apparmor message where the name="" was missing > > the leading / and was advised to use the attach_disconnected flag. > > I'm getting a similar message again: > > > > type=AVC msg=audit(1530626112.960:424568): apparmor="DENIED" > > operation="open" > > info="Failed name lookup - disconnected path" error=-13 > > profile="/usr/sbin/apache2//indexcgi" name="var/thing/data/.plain" > > pid=6195 comm="index.cgi" requested_mask="rw" denied_mask="rw" fsuid=33 > > ouid=0 > > > > > > I searched for documentation on the attach_disconnected flag and eventually > > found: > > > > > > https://www.suse.com/documentation/sles-12/book_security/data/sec_apparmor_profiles_glob.html > > Attach flags consist of two pairs of mutually exclusive flags: > > attach_disconnected or no_attach_disconnected (determine if > > path names resolved to be outside of the namespace are > > attached to the root, which means they have the '/' character > > at the beginning), and chroot_attach or chroot_no_attach > > (control path name generation when in a chroot environment > > while a file is accessed that is external to the chroot but > > within the namespace). > > > > Under what circumstances would path names resolve to be outside of the > > namespace? > > there are several cases. It generally involves an fd that was opened outside > of the > namespace and "passed in". The "passed in" could be via some fd passing > scheme, > process inheritance - file open at exec, process inheritance - file open at > clone newns, > unshare, setns, or file open at pivot_root/chroot with the fd outside of the > new root. > > In all of these cases the fd referenced mount point is outside of the mount > ns, and > so there is no proper way place the fd within the file tree.
Thanks. I guessed that chroot could cause it but there's at lot more to it than that. In my case, I expect that it has something to do with an ecryptfs mounted file system that was mentioned in the log message. > > I'm wondering if there's any reason not to always use the > > attach_disconnected flag. > > I assume there must be since no_attach_disconnected seems to be the default. > > Because it was a debug flag, and not intended for use during mediation. It > causes > aliasing in the profile and reduces your security. Unfortunately it is also > currently > the only way to deal with disconnected files, whose use have exploded in > recent years > due to containers. Thanks. Luckily, I can now just apply it to the one profile that needs it. > There are a couple of different fixes in the works to deal with this problem. > Once > they land this flag will be deprecated and removed as fast possible (which > will > sadly be years). And a few more years after that before it gets to debian stable. :-) cheeers, raf -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
