A MAC policy should be extremely fine-grained, not necessarily extremely restrictive.
It can decrease security under certain conditions. Applications, especially complex ones, often have fallbacks when a given resource cannot be accessed. The reasons for this can be anything from being unable to access a security service to entering an insecure compatibility mode for an older and less secure system. Sometimes the issue is simply that the application has not been thoroughly tested and being unable to access a normally present resource leads to security bugs.
As mentioned in a comment, the secret service on many Linux environments provides an API for securing passwords, without which browsers and other applications may attempt to store passwords internally, potentially with less security.
LibreSSL infamously attempts to generate its own randomness from the environment if it cannot read the randomness character devices or any other fallbacks, leading to predictable output. This issue has actually lead to the development of a randomness syscall so applications can access entropy even in overly restrictive MACs or chroots.
Programs with PAM support will not be able to obey PAM policies if they cannot access the relevant libraries and configuration files. Breaking PAM doesn't directly reduce security as the fallback is to access system passwords through the normal methods, but it can break complex policies that increase security. This may, for example, break keycard recognition.
When developing an access control policy, it is important that none of the normal resource access attempts for whitelisted applications are denied unless you have a solid understanding of all of the implications of denying the resource. For example, denying access to
/etc/localtime is likely to result in an application using UTC time only, whereas blocking access to a standard file guaranteed to exist on all systems may cause unforeseen and severe bugs. When a denied access is triggered, the event should be logged for later review. If you find out that the access is benign and not likely to increase attack surface, you can add it to the whitelist.
I suggest you look into AppArmor abstractions which allow the inclusion of sub-policies with specific purposes, such as whitelisting audio access. This allows you to simplify your policy by adding an
#include <abstractions/audio> rather than having to whitelist individual objects. This makes AppArmor policies significantly simpler than they otherwise would be, while still maintaining a high level of security. Many MAC architectures support a similar feature.