The application should not depend on having directory write permission outside /tmp, /var/tmp, invoking user's home directory and /var/opt/package, (where package is the name of the application package).
The application should not depend on owning these directories.
For these directories the application should be able to work with directory write permissions restricted by the "sticky bit". (Which prevents the application from removing files owned by another user. This is classically done with /tmp, to prevent accidental deletion of "foreign" files.)
The application should not depend on file write permission on files not owned by the user it runs under with the exception of its personal inbox /var/mail/username
The application should not depend on having read permission to every file and directory.
The application should not depend on the suid/sgid permissions of a file not packaged with the application. Instead, the distribution is responsible for assuming that all system commands have the required permissions and work correctly.
Rationale: Let us make security officers happy. Let's give them the freedom to take sgid/suid perms away, as long as they do not break the system's functionality.
"Normal" applications should not depend on running as a privileged user.
Special applications that have a reason to run under a privileged user, should outline these reasons clearly in their documentation, if they are not obvious as in the case of a backup/restore program. Users of the application should be informed, that "this application demands security privileges, which could interfere with system security".
The application should not contain binary-only software that requires being run as root, as this makes security auditing harder or even impossible.
The application should not change permissions of files and directories that do not belong to its own package. To do so without a warning notice in the documentation is regarded as unfriendly act.
Applications that expect to be runnable from removable media should not depend on logging in as a privileged user, and should be prepared to deal with a restrictive environment. Examples of such restrictions could be default mount options that disable set-user/group-ID attributes, disabling block or character-special files on the medium, or remapping the user/group IDs of files away from 0. [1]
If the installation of an application requires the execution of programs with superuser privileges, such programs should also be supplied in a human-readable form.
Without this, the local system administrator would have to blindly trust a piece of software, particularly its security.
| [1] | Rationale: System vendors and local system administrators want to run applications from removable media, but want the possibility to control what the application can do. |