confcall followup: [PROPOSAL V2] (Ch.16 FHS) file/dir permissions
(As discussed in the last LSB conference call)
----------------------------------------------------------
Reworded proposal to add the following to chapter 16:
( comments from Alan Cox: changes of #3)
( comments from John Terpstra: Add #6)
In this Chapter "System" means a "LSB compliant system" and
"application" means a "LSB compliant (third party vendor) application".
1. Directory Write Permissions
o The application must not depend on having directory write
permission outside /tmp, /var/tmp and it´s 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. File Write Permissions
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>
3. 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 to the application read and execute
| permissions needed to use all system interfaces (ABIs)
| mentioned in the LSB document and included standards.
4. 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 correctly doing their job 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.
| 5. Privileged users
|
| Application may not depend on running as a privileged user
|
| [ If we can not agree on that (which I am in favor of), let us
| at least state this as a minimum:
|
| If an application wants to run under a privileged user,
| then
| o The reasons must be outlined clearly
| o It must be prominently and verbatimly stated in all announcments
| of the application that "this application demands security
| privileges, which could infere with system security".
| o The application may not contain binary only software.
| ]
| 6. Changing permissions
|
| Application must not change permissions of files and
| directories not beeing part of their package
7. Removable Media (Cdrom, Floppy,...)
o The 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 systems to prevent application from bad behaviour.
8. Run-from-removable media applications
o They must not depend on logging in as a privileged user.
9. Installable applications (This paragraph should possibly be part
of Chapter VII. - Package Format and Installation)
On Installation, they 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.
Rationale/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.
--
______ ___
/ ___/__/ / 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: