[apparmor] Question about attach_disconnected

[John Johansen]

On 07/04/2018 07:37 PM, apparmor at raf.org wrote:
> 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. :-)
> 
sigh too true, the goal is to land both delegation and fsmount conditionals this
year upstream.