Valdis.Kletnieksat_private wrote: > I originally thought that our esteemed colleage Mr Jones was good and > thoroughly high on crack when he started this thread, but now I see > the issue in question. autoconf/configure type programs often run tests > to see if Feature X is available on the system - and good security practice > says that you do your configure/make work as non-root, and only use root > for the final install. A common application practice is to check if it ought to be able to complete a complex, multistep operation prior to starting. Since modern computer systems do not provide a handy interface for doing this the application will use stat(), access(), fsstat(), and anything else the developer can think of to check the state of resources. When the developer does everything she can to determine accessability, all the answers say yes, and access is denied, she is understandably unhappy. This has been a longstanding issue in the trusted systems world. Any change to the policy makes 3rd party installation scripts fail, especially those which check for access and proceed based on the information returned. Yes, I know, all applications should be written to deal with failures. To do so, they need to know the policies being enforced. They need a way to find this out. -- Casey Schaufler Manager, Trust Technology, SGI caseyat_private voice: 650.933.1634 casey_pat_private Pager: 888.220.0607 _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Fri Jan 25 2002 - 10:19:22 PST