[apparmor] Question about attach_disconnected
apparmor at raf.org
apparmor at raf.org
Thu Jul 5 02:37:40 UTC 2018
John Johansen wrote:
> On 07/03/2018 04:41 PM, apparmor at 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. :-)
cheeers,
raf
More information about the AppArmor
mailing list