|Linux Standard Base Core Specification 3.0Preview1|
|<<< Previous||Chapter 5. Additional Recommendations||Next >>>|
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
S_ISVTXT bit (otherwise known as the "sticky bit").
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 set user ID or set group ID
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: In order to implement common security policies it is strongly advisable for applications to use the minimum set of security attributes necessary for correct operation. Applications that require substantial appropriate privilege are likely to cause problems with such security policies.
In general, applications should not depend on running as a privileged user. This specification uses the term "appropriate privilege" throughout to identify operations that cannot be achieved without some special granting of additional privilege.
Applications that have a reason to run with appropriate privilege should outline this reason clearly in their documentation. 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 with appropriate privilege, as this makes security auditing harder or even impossible.
The application shall not change permissions of files and directories that do not belong to its own package. Should an application require that certain files and directories not directly belonging to the package have a particular ownership, the application shall document this requirement, and may fail during installation if the permissions on these files is inappropriate.
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 and group IDs of files away from any privileged value.
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.
Where the installation of an application needs additional privileges, it must clearly document all files and system databases that are modified outside of those in /opt/pkg-name and /var/opt/pkg-name, other than those that may be updated by system logging or auditing activities.
Without this, the local system administrator would have to blindly trust a piece of software, particularly with respect to its security.