[apparmor] Question about attach_disconnected

[John Johansen]

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.


> 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.

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).