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