[apparmor] Question about attach_disconnected

[apparmor at raf.org]

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