On 07/04/2018 07:37 PM, appar...@raf.org wrote: > John Johansen wrote: > >> On 07/03/2018 04:41 PM, appar...@raf.org 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. :-) > sigh too true, the goal is to land both delegation and fsmount conditionals this year upstream.
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
