Hey, I think everything in the gnutls/ directory should be allowed: there can be profiles with arbitrary names (or at least alnum I guess) which define priority/configuration strings that can be used by gnutls applications. I'm not aware of anything else that typically goes there but I haven't checked. I'll have another look today.
More generally, there can be the same issue for openssl which has its own abstraction file but isn't included by default AFAIU. A similar issue could apply to ssl_certs since some apps/libraries ship their own cert bundle and could function despite not having access to the system store (I'm looking at you python). I don't know what would be a typical behavior here but I'm pretty sure that the whole range of possible behavior exists in the wild. I'm wondering if I understood the current rules fine because based on my understanding, I would have expected warnings for these too. A noteworthy change is https://bugs.launchpad.net/ubuntu/+source/nss/+bug/2016303 : it would access to /etc/nss . I don't know if NSS silently ignores inaccessible system-wide configuration or not. You might want to include it already. I think all these libraries should probably fail on EPERM. Probably 0 change upstreams accept such a change if it's needed however. :P -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2056739 Title: apparmor="DENIED" operation="open" class="file" profile="virt-aa- helper" name="/etc/gnutls/config" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2056739/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
