[apparmor] logs with name="not an absolute path" or name=HEXSTRING

John Johansen john.johansen at canonical.com
Wed Dec 20 05:11:26 UTC 2017


On 12/19/2017 06:56 PM, apparmor at raf.org wrote:
> Hi,
> 
> debian9 (with auditd)
> apparmor-2.11.0-3
> apparmor-profiles-2.11.0-3
> apparmor-profiles-extra-1.11
> 
> I'm seeing odd apparmor log messages where the name parameter
> is not an absolute file system path.

The file is disconnected from the tasks namespace. This usually
happens because the task has been placed in a new fs namespace.

Ideally you would use delegation to deal with this but at the
moment the only way to deal with it is a hack. In the profile
flags set attach_disconnected.

profile /foo flags=(attach_disconnected) {
  ...
}

profile /foo flags=(complain, attach_disconnected) {
  ...
}

this will prepend / to the path to connect it to the root.

> 
> They look like:
> 
>   type=AVC msg=audit(1513725614.403:1142439): apparmor="ALLOWED"
>   operation="getattr" info="Failed name lookup - disconnected path"
>   error=-13 profile="/usr/lib/dovecot/imap"
>   name="var/vmailboxes/user at domain.com/Maildir/dovecot.index.log"
>   pid=21232 comm="imap" requested_mask="r" denied_mask="r" fsuid=104 ouid=104
> 
> There is a /var/vmailboxes... and I have rules for it.
> 
> Any idea why the leading / is missing from the log message?
> 
the file doesn't exist in the tasks fs namespace

> It's a syntax error to have a rule that isn't for an absolute path.
> 
correct

> I'm also seeing log messages where the name is a hex string
> representation of a path (without double quotes).
> 
> e.g. name=7661722F766D616...
> 
> Is there a way to prevent this.

no the audit subsystem (its not even apparmor at this point) is
hex encoding the string because it has an unsafe character like
 a space

you can decode these with aa-decode

> It means I need to decode paths in log messages before
> I can add new rules to make the log messages go away.
> 
unfortunately yes. I need to finish a patch to the log parsing lib
that will do this transparently, so logprof with just work with
this.





More information about the AppArmor mailing list