If SELinux is enabled, the policy defines what access to resources and operations on them (e.g. read, write) are allowed (i.e. SELinux stops all access unless allowed by policy). This is why SELinux is called a ‘mandatory access control’ (MAC) system.
The policy design, implementation and testing against a defined security policy or requirements is important, otherwise there could be ‘a false sense of security’.
SELinux can confine an application within its own ‘domain’ and allow it to have the minimum privileges required to do its job. Should the application require access to networks or other applications (or their data), then (as part of the security policy design), this access would need to be granted (so at least it is known what interactions are allowed and what are not – a good security goal).
Should an application ‘do something’ it is not allowed by policy (intentional or otherwise), then SELinux would stop these actions.
Should an application ‘do something’ it is allowed by policy, then SELinux may contain any damage that maybe done intentional or otherwise. For example if an application is allowed to delete all of its data files or database entries, and the bug, virus or malicious user gains these privileges then it would be able to do the same, however the good news is that if the policy ‘confined’ the application and data, all your other data should still be there.
User login sessions can be confined to their own domains. This allows clients they run to be given only the privileges they need (e.g. admin users, sales staff users, HR staff users etc.). This again will confine/limit any damage or leakage of data.
Some applications (X-Windows for example) are difficult to confine as they are generally designed to have total access to all resources. SELinux can generally overcome these issues by providing sandboxing services.
SELinux will not stop memory leaks or buffer over-runs (because its not designed to do this), however it may contain the damage that maybe done.
SELinux will not stop all viruses/malware getting into the system (as there are many ways they could be introduced (including by legitimate users), however it should limit the damage or leaks they cause.
SELinux will not stop kernel vulnerabilities, however it may limit their effects.
It is very easy to add new rules to an SELinux policy using tools such as audit2allow(1) if a user has the relevant permissions, however be aware that this may start opening holes, so check what rules are really required.
Finally, SELinux cannot stop anything allowed by the security policy, so good design is important.