Why is reading and editing an AppArmor profile considered far more approachable than working with an SELinux policy?

A daemon already runs under its own restricted account with the right rwx permissions, yet you also want the kernel to stop it touching directories it has no business in even if it is hijacked. What extra layer provides this?

When a running process violates an SELinux rule, many people assume SELinux kills the offending program. What does it actually do?

Administrators frequently switch SELinux off the moment the first problem appears. What two structural criticisms of SELinux drive that reaction?

SELinux is described as resting on two pillars. What are they, and why is the first pillar useless without correct data?

You want to see the SELinux context of a file. Which command shows it, and where is that context physically stored?

A file ended up with the wrong SELinux context. You reach for restorecon vs chcon — what is the practical difference between the two?