Symbian OS Platform Security/02. Platform Security Concepts - Revision history

Craig: minor clarification

2011-01-17T13:42:27Z

minor clarification

Craig: /* \sys */ Added note that data caging doesn't prevent copying of binaries from SIS files

2011-01-17T13:26:09Z

‎\sys: Added note that data caging doesn't prevent copying of binaries from SIS files

Craig: removed category, added copyright template

2011-01-17T11:48:41Z

removed category, added copyright template

Craig: chapter author, navigation links, figure and table fomatting

2011-01-06T16:46:50Z

chapter author, navigation links, figure and table fomatting

Craig: lots of formatting fixes

2010-12-22T23:26:57Z

lots of formatting fixes

Show changes

Craig: added backup link

2010-12-20T22:32:32Z

added backup link

Admin: 19 revisions: import from developer.symbian.org

2010-12-18T16:03:11Z

19 revisions: import from developer.symbian.org

Stichbury: moved Symbian OS Platform Security/2. Platform Security Concepts to Symbian OS Platform Security/02. Platform Security Concepts

2010-03-24T11:48:05Z

moved Symbian OS Platform Security/2. Platform Security Concepts to Symbian OS Platform Security/02. Platform Security Concepts

Hamishwillee: moved Chapter 2: Platform Security Concepts to Symbian OS Platform Security/2. Platform Security Concepts: Move book to sub-page model

2010-03-17T22:16:55Z

moved Chapter 2: Platform Security Concepts to Symbian OS Platform Security/2. Platform Security Concepts: Move book to sub-page model

Satudahl at 13:45, 12 March 2010

2010-03-12T13:45:23Z

@@ Line 798: / Line 798: @@
 {|border="1" cellspacing="0" cellpadding="8"
-|Note that, although application binaries are protected from being read and copied after they are installed in {{Icode|\sys\bin}}, there is no automatic protection of application binaries when they are delivered to the device in a SIS file (see [[Symbian OS Platform Security/08. Native Software Installer#SIS_File_Changes_for_Platform_Security|Chapter 8]]).  Application SIS files should be delivered in a DRM wrapper if copy protection is needed.
+|Note that, although application binaries are protected from being read and copied after they are installed in {{Icode|\sys\bin}}, there is no automatic protection of application binaries at the time they are delivered to the device in a SIS file (see [[Symbian OS Platform Security/08. Native Software Installer#SIS_File_Changes_for_Platform_Security|Chapter 8]]).  Application SIS files should be delivered in a DRM wrapper if copy protection is needed.
 |}

@@ Line 796: / Line 796: @@
 in another, non-Symbian OS device. This directory is managed by the
 software installer, which we will cover in more detail in Chapter 8.
 ==={{Icode|\resource}}===

← Older revision		Revision as of 11:48, 17 January 2011
Line 905:		Line 905:
	design of software.		design of software.

−	~~[[Category:Book]]~~	+	{{SymbianOSPlatformSecurity_Copyright}}

@@ Line 1: / Line 1: @@
 {| width="100%"
 |-
-|Reproduced by kind permission of John Wiley & Sons.||align="right"|[[Symbian OS Platform Security|Table of Contents]]
+|'''by Simon Higginson'''||align="center"|Reproduced by kind permission of John Wiley & Sons.||align="right"|'''[[Symbian OS Platform Security/01. Why a Secure Platform?|Prev.]] &nbsp; [[Symbian OS Platform Security|Contents]] &nbsp; [[Symbian OS Platform Security/03. The Platform Security Environment|Next]]'''
 |}
@@ Line 252: / Line 252: @@
 completely untrustworthy. This is shown in Figure 2.1.
-[[File:Figure 2.1.jpg]]
+[[File:Figure 2.1.jpg|frame|none|'''Figure 2.1''' Tiers of Trust]]
-{|align="center"
 |'''Figure 2.1''' Tiers of Trust
-|}
 What does it mean for Symbian OS to decide the trustworthiness of a
@@ Line 464: / Line 461: @@
 correct authorization (digital signature).
-[[File:Figure 2.2.jpg]]
+[[File:Figure 2.2.jpg|frame|none|'''Figure 2.2''' Categories of Capability]]
-{|align="center"
 |'''Figure 2.2''' Categories of Capability
-|}
 Capabilities are ''discrete'' and ''orthogonal''. This means they are not
@@ Line 495: / Line 489: @@
 ==System Capabilities==
-[[File:Figure 2.3.jpg]]
+[[File:Figure 2.3.jpg|frame|none|'''Figure 2.3''' System Server Enforcing System Capabilities]]
-{|align="center"
 |'''Figure 2.3''' System Server Enforcing System Capabilities
-|}
 The largest group of capabilities is the system capabilities. The granting
@@ Line 520: / Line 511: @@
 on the use of each capability is provided in Appendix A.
-'''Table 2.1''' System Capabilities
+{| border="1" cellpadding="6" cellspacing="0"
-{| border="1" cellpadding="4" cellspacing="0"
+|+'''Table 2.1''' System Capabilities
 !Capability !! Privilege Granted
 |-
@@ Line 572: / Line 563: @@
 shown in Figure 2.4:
-[[File:Figure 2.4.jpg]]
+[[File:Figure 2.4.jpg|frame|none|'''Figure 2.4''' System Server Enforcing User Capabilities]]
-{|align="center"
 |'''Figure 2.4''' System Server Enforcing User Capabilities
-|}
-'''Table 2.2''' User Capabilities
+{| Border="1" cellspacing="0" cellpadding="6"
-{| Border="1" cellspacing="0" cellpadding="4"
+|+'''Table 2.2''' User Capabilities
 !Capability !! Privilege Granted
 |-
@@ Line 674: / Line 662: @@
 Figure 2.5 – capabilities declared in the binaries are shown as ‘C''n''’:
-[[File:Figure 2.5.jpg]]
+[[File:Figure 2.5.jpg|frame|none|'''Figure 2.5''' Direct Loading of DLLs]]
-{|align="center"
 |'''Figure 2.5 Direct Loading of DLLs
-|}
 Rule 2 has some interesting consequences for ''statically-linked'' DLLs.Most
@@ Line 690: / Line 675: @@
 the second DLL does not have, as in Figure 2.6.
-[[File:Figure 2.6.jpg]]
+[[File:Figure 2.6.jpg|frame|none|'''Figure 2.6''' Static Linking of DLLs]]
-{|align="center"
 |'''Figure 2.6''' Static Linking of DLLs
-|}
 In this case, because DLL1 is statically linked to DLL2, DLL1 can never be
@@ Line 703: / Line 685: @@
 '''Rule 2b: The loader will only load a DLL that statically links to a second DLL if that second DLL is trusted with at least the same capabilities as the first DLL.'''
-[[File:Figure 2.7.jpg]]
+[[File:Figure 2.7.jpg|frame|none|'''Figure 2.7''' Indirect Loading of DLLs]]
-{|align="center"
 |'''Figure 2.7''' Indirect Loading of DLLs
-|}
 If a DLL that has already been loaded for another process is being reused,
@@ Line 778: / Line 757: @@
 The consequence of the access rules being implied by the full path to a file is that, should the developer want to limit access, the file only needs be moved to another directory. The access rules are summarized in Table 2.3.
-'''Table 2.3''' Data Caging Access Rules
+{| border="1" cellspacing="0" cellpadding="6"
-{| Border="1" cellspacing="0" cellpadding="4"
+|+'''Table 2.3''' Data Caging Access Rules
-! Directory Path !! Capability Required To: !!
+!rowspan="2"|Directory Path!!colspan="2"|Capability Required To:
 |-
-!  !! Read !! Write
+! Read !! Write
 |-
 | {{Icode|\sys}}|| {{Icode|AllFiles}} ||{{Icode|Tcb}}

← Older revision		Revision as of 22:32, 20 December 2010
Line 1:		Line 1:
−	Reproduced by kind permission of John Wiley & Sons.	+	{\| width="100%"
		+	\|-
		+	\|Reproduced by kind permission of John Wiley & Sons.\|\|align="right"\|[[Symbian OS Platform Security\|Table of Contents]]
		+	\|}

	=Background Security Principles=		=Background Security Principles=

← Older revision	Revision as of 16:03, 18 December 2010
(No difference)

← Older revision	Revision as of 11:48, 24 March 2010
(No difference)

← Older revision	Revision as of 22:16, 17 March 2010
(No difference)

← Older revision		Revision as of 13:45, 12 March 2010
Line 1:		Line 1:
		+	Reproduced by kind permission of John Wiley & Sons.
		+
	=Background Security Principles=		=Background Security Principles=
	Symbian has a long history of reuse – Symbian OS came from Psion, along		Symbian has a long history of reuse – Symbian OS came from Psion, along