An alternative approach to presenting the sandbox is to define what untrusted applets can do. After all, if applets were allowed to do nothing, security concerns would be completely alleviated. In order to run, untrusted applets require access to the CPU of the client machine as well as access to memory in which to build objects. Access to both of these resources is completely controlled by the VM. The default sandbox for untrusted applets also includes access to the Web server from which the applet was downloaded. Programmers not used to such constraints often complain that the default sandbox is too restrictive; for example, the inability to read and write temporary files must be designed around. The good news (for developers, anyway) is that Java 2 allows the user to give a digitally signed applet access to more local resources. The bad news (for users and administrators) is that in terms of the usual tradeoff between functionality and security, more powerful applets present more risk. In any case, applet developers are likely to code their applets to make use of local files, peripherals, and networked resources. Then the applets will be digitally signed. In order for a signed applet to run on a client machine, the administrator of the machine must set up a security policy that grants the particular applet access to the resources it needs. Setting up and administering these policies is not a trivial exercise. See Chapter 3 for more on these issues.
Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Copyright ©1999 Gary McGraw and Edward Felten. |
