By default there is no particular integrity protection for system program and library files beyond file permissions (and possibly read-only mounting); there is no such thing as specially protected system files. In this sense, the answer is yes, this is true.
You could follow a host-based IDS approach using programs like tripwire or aide, where you create suitable checksums for each important file, store them in a safe place, and compare them regularly against the actual re-calculated checksums to notice any changes. Clearly, the database of checksums needs to be updated upon the installation of every single update or patch. Most package managers maintain such a list of checksums and allow to check the integrity of the installed files. This approach, if followed in meaningful ways, is a bit involved and therefore rarely seen.
A different approach is to harden the system against integrity violations by using add-ons for role-based access control (RBAC) and mandatory access control (MAC) like SELinux or Grsecurity, where, if applied correctly, even root could not modify system files unless it enters a designated role. The key here is to design a policy that inhibits undesired actions while not breaking legitimate application activity. This is far from trivial and therefore rarely seen, either.
However, before any of this is considered in depth, one needs to define the attack model and to specify the scenario: 20 years ago Unix machines were true multi-user systems where potentially not trustworthy users had access to the system. These days are gone; today you have servers with functional users such as "webserver" or "database", or you have desktop systems on personal computers with one user.