Stephen Smalley wrote: >On Fri, 2004-10-08 at 22:50, Niki Rahimi wrote: > > >>+1. Trusted user, trusted path = User is able to run the executable. >>+2. Trusted user, untrusted path = User is able to run the >>executable. >>+3. Untrusted user, trusted path = User is able to run the executable. >>+4. Untrusted user, untrusted path = User is not able to run the >>executable. >>+ >>+In short, if the path and user are both untrusted, execution will be >>denied. >> >> >Can you give a practical example of how this security model is useful? >Even given a correct implementation, how does it prevent untrusted users >from executing arbitrary code via an interpreter in a trusted path? > > "untrusted" does not mean what you think it means :) In this case, substitute "clueless" or "careless" in place of "untrusted". The purpose is a pathology-preventer to prevent sloppy users from accidentally executing Trojan code inserted by a malicious user. Crispin -- Crispin Cowan, Ph.D. http://immunix.com/~crispin/ CTO, Immunix http://immunix.com
This archive was generated by hypermail 2.1.3 : Tue Oct 12 2004 - 19:04:51 PDT