Mathias is correct, the hint messages are only emitted when a profile is
in learning mode. Setting the profile to enforce mode will stop the
hint messages.
--
apparmor-profiles: nscd profile spams my logs
https://bugs.launchpad.net/bugs/144383
You received this bug notification because you are a
a dmesg dump would be good too.
--
apparmor Segmentation fault
https://bugs.launchpad.net/bugs/140626
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.co
Kees is right,
AppArmor composes capabilities, so as long as AppArmor is loaded
capabilities are being enforced, whether or not applications are
confined or unconfined. AppArmor's additional capability mediation that
is specified in profiles is applied after standard capability mediation
is appli
It sounds like there are two or more rules in the profile that overlap
and have conflicting x mods. AppArmor requires that there is only a
single x mode for any given match
eg.
/usr/lib/cups/filter/* Ux,
/usr/lib/** ix,
will conflict because the rule with ix overlaps the rule using Ux. The
dfa
This is an intentional change and bug fix in the new AppArmor. The old
AppArmor was always supposed to
mediate write access to directories, but due to a bug in the code it would not
under most circumstances.
AppArmor does mask and implicitly allow directory traversal (unix dac x perm on
directo
While I agree this is something needs to address with mount rules, I
can't give an eta for when it will happen.
In the mean time is it feasible to use variables so the prefixes can be
all added in one place?
--
fails to start: cannot apply additional memory protection after relocation
https://bu
For both of these cases, if you look in /var/log/messages you can see
that AppArmor is rejecting access to
/rofs/lib/tls/i686/cmov/libc-2.6.1.so
A simple fix is to update the profiles to use
{/rofs,/cow,}/lib/tls/i686/cmov/*.so
AppArmor can block access to stacked filesystem paths depending on ho
With the current AppArmor code running the AppArmor init script right
after mountall is the best solution. A feature on the AppArmor wish
list is extremely early init.
The current plans are to have apparmor initialize as early as possible,
the security_initcall level instead of module_init level
Updating profiles is a pain and known problem. The current plans for
dealing with this are two fold. We have been working on a merge tool,
which will allow two and three way profile merging. The tool will
provide both automatic and manual merging of profiles. The other way of
dealing with this
