Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...

Chapter 6. Security in Open Source Software
meta model, a meta model is called open meta model, a model open model, and an application
(or software), of course, open source.
This means that most parts of the software for this work should be developed (and published)
as open meta model and open model. Only the domain framework, generators, and parts of
the verification and validation suite apply directly to the term open source.
This approach leads to a security related problem because parts of the architecture can
or should be (re)implemented or extended by users / suppliers. As explained in Chapter 5,
the developed software should be verified, validated, and certified, which cannot be done
for (later) additional implemented software from third-parties in advance. This means that
verification and validation cannot be assured for all parts of the openETCS software because
the third-party implementations from other users / suppliers can only be verified and validated
by their developers or later in an additional process. Therefore, it have to be assumed that
third-party software that is not verified and validated does not comply with the EN 50128
(Subsection 5.1.2) and may even hold faulty or malicious software, e.g., a Backdoor. Malicious
software may even compromise software parts that were verified and validated before.
On the other hand, if additional supplier implementations are validated and certified, this
has to be done for the additional software, the open source, and the open model software
together. The result is an extensive process because all possible impacts of the additional
software to the already certified open source and open model software have to be analysed.
Figure 6.2 shows a very general example of how a third-party or supplier implementation
could compromise other parts of an open model software. This example has one model
implementation, which is certified, because it was directly generated from the certified open
model. Additionally, it holds two supplier implementations, which both instantiates certain
model parts of the open model software. These supplier implementations cannot guarantee
to be certified whereas one of them holds even malicious code. The communication between
different implementation parts is often required. A typical method is the usage of shared
memory. This means two (or more) implementations read and write to same areas in the
memory to communicate. Unfortunately, this mechanism can also be misused to compromise
other implementation parts. Therefore, the malicious supplier implementation could access the
memory of any other implementation and change their data used for execution or even the
execution itself.
Measures and techniques should be found to minimise the possible influence of a faulty or
malicious supplier implementation. Already existing strategies and a novel approach with the
usage hardware virtualisation are introduced and compared in the following sections and are
also described in [26].
In the following section, traditional methods for the management of memory are shortly
explained followed by the description of concepts for the usage of hardware virtualisation as a
new strategy. Afterwards, certain problems related to hardware virtualisation are discussed.
Possible solutions are elaborated and presented, which will be used for the case study in
Part III.
66