[PROPOSAL] (Ch.16 FHS) be more specific on file/dir permissions
This proposal is also checked in into George Krafts Comment submission form
Problem:
LSB says nothing about File Permissions.
o This makes it possible to set up an LSB-conforming package
and a LSB conforming Linux system where the application can
not run on the linux system.
o LSB-conforming systems should be allowed to use very restrictive
permission schemes, not to make security and LSB a contradiction.
Consequences:
o LSB conforming applications should run with very restrictive
file permissions
o LSB-conforming systems should not be required to give much
file permissions.
Proposal:
In this proposal "System" means a "LSB compliant system" and
"application" means a "LSB compliant application".
I. Write Permissions
1. Directories
o The application must not depend on having directory write
permission outside /tmp, /var/tmp and his home directory.
o The application must not depend on owning these directories.
o The system may restrict directory write permissions for these
directories by setting the "sticky bit" for them.
( To prevent the application to remove "foreign" files,
e.g. a empty .rhosts file owned by root.)
2. Files
The application must not depend on file write permission on
files not owned by the user it runs under with the exeption
of its personal inbox /var/mail/<username>
II. Read Permissions and Execute Permissions
o The application must not depend on having read permission to
every file and directory.
o The system must grant the permissions needed to use them
to all libraries, executables and data files mentioned in the
LSB document, and included standards.
III. Suid and Sgid Permissions
The application must not depend on suid/sgid permissions on a
file. Instead, the system is responsible that all system commands
are just doing their job right and have the permissions needed.
Rationale:
Let us make security officers happy. Lets give them the freedom
to take sgid/suid perms away, as long as they do not break
the systems funtionality.
IV. Removable Media (Cdrom, Floppy,...)
o LSB systems may use mount options "noauto", "nouser",
"nosuid" and "nodev" for removeable media. Also
"uid=X", "gid=X" may be used with a non-zero uid/gid value X.
Rationale: allow running applications from removable media, but
allow system to prevent application from bad behaviour.
V. Run-from-removable media applications
o They must not depend on logging in as user root.
VI.Installable applications (This paragraph should possibly be part
of Chapter VII. - Package Format and Installation)
These must not depend on BOTH to
o log in as user root
o run a self-supplied binary install routine
Rationale:
Let us make security officers less unhappy.
--
______ ___
/ ___/__/ / Caldera (Deutschland) GmbH
/ /_/ _ / /__ Naegelsbachstr. 49c, 91052 Erlangen, Germany
/_____/_/ /____/ software developer / lsb project
==== /____/ ===== Dipl. Inf. Johannes Poehlmann, mail: jhp@caldera.de
Caldera OpenLinux phone: ++49 9131 7192 336, fax: ++49 9131 7192 399
----- End forwarded message -----
--
______ ___
/ ___/__/ / Caldera (Deutschland) GmbH
/ /_/ _ / /__ Naegelsbachstr. 49c, 91052 Erlangen, Germany
/_____/_/ /____/ software developer / lsb project
==== /____/ ===== Dipl. Inf. Johannes Poehlmann, mail: jhp@caldera.de
Caldera OpenLinux phone: ++49 9131 7192 336, fax: ++49 9131 7192 399
----- End forwarded message -----
--
______ ___
/ ___/__/ / Caldera (Deutschland) GmbH
/ /_/ _ / /__ Naegelsbachstr. 49c, 91052 Erlangen, Germany
/_____/_/ /____/ software developer / lsb project
==== /____/ ===== Dipl. Inf. Johannes Poehlmann, mail: jhp@caldera.de
Caldera OpenLinux phone: ++49 9131 7192 336, fax: ++49 9131 7192 399
Reply to: