[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.
 	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 

         Let us make security officers less unhappy.

     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.
     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: