Information Flow Secure CAmkES

Amit Goyal, Akshat Garg, Digvijaysingh Gour, R. K. Shyamasundar and G. Sivakumar

Department of Computer Science and Engineering,

Indian Institute of Technology Bombay, Mumbai, India

Keywords:

Access Control, Conﬁdentiality, Integrity, Information Flow Security, seL4, CAmkES, RWFM.

Abstract:

Component Architecture for microkernel-based Embedded Systems (CAmkES) is a framework used to build

embedded systems software on the top of seL4. seL4, a general purpose microkernel, uses the underlying

Discretionary Access Control (DAC) capability model to ensure conﬁdentiality and integrity of the systems

built on it. These systems are not information ﬂow secure as DAC model only considers direct read/write

accesses and does not consider the indirect accesses. In indirect access, an unauthorized subject can get access

to an object through another subject which has the direct access to that object. In this paper, we model and

implement information ﬂow secure CAmkES (IFS-CAmkES) which ensures complete mediation by RWFM

monitor which is based upon Readers Writers Flow Model (RWFM), a Mandatory Access Control (MAC)

model. IFS-CAmkES can be considered as CAmkES enriched with MAC based security. Prototypes of some

real life examples have been implemented on IFS-CAmkES. We also compare the performance of CAmkES

and IFS-CAmkES based systems.

1 INTRODUCTION

In today’s digital world, security is one of the major

aspects that needs to be addressed, even though, in

the operating system (in use), there is no clear layer

for this attribute (Lampson, 2011). Additionally, in

the context of Internet of Things (IoT), consisting of

interconnected embedded systems, security cannot be

thought of as an add-on to a device, but rather inte-

gral to the reliable functioning of the device. Soft-

ware security controls need to be introduced at the

operating system level which takes off the onus from

device designers and developers to conﬁgure systems

to mitigate threats, and ensure their platforms are safe.

Further, there has always been a trade off between se-

curity and functionality (Jaeger, 2008). Most of the

secure systems are either hard or not usable in prac-

tice because of the limited functionality.

There have been several attempts towards prov-

ing security properties of the operating systems but

most of the proofs are either incomplete, require man-

ual intervention or work at the high level abstrac-

tion and not at the implementation level (Klein et al.,

2014). seL4 is a general purpose microkernel which

has been fully formally machine veriﬁed and proofs

carry through the high level abstractions down to the

C code implementation (Klein et al., 2009). seL4 has

small Trusted Computing Base (TCB) which makes it

embedded system friendly, and its veriﬁcation feasi-

ble (Heiser et al., 2007). Its strong isolation enforce-

ment between mutually distrusting components, run-

ning on its top, makes it a perfect candidate to be used

as a hypervisor(to host virtual machines) (Klein et al.,

2018).

Systems built on seL4 have been veriﬁed to pro-

vide conﬁdentiality, integrity, authority conﬁnement

and availability (Klein et al., 2014) (Elkaduwe et al.,

2008). These systems only prevent the unauthorized

direct read/write accesses of a subject to an object

(owing to the capability based, Discretionary Access

Control (DAC) implementation of seL4) but do not

prevent the indirect accesses which lead to the infor-

mation leak. In indirect access, an authorized sub-

ject, having direct access to an object, helps an unau-

thorized subject to get access to that object. This

might involve multiple intermediary subjects and ob-

jects which ultimately aid an unauthorized subject in

getting the access.

Component Architecture for microkernel-based

Embedded Systems (CAmkES) is a platform which

aids in building embedded systems software on seL4.

It abstracts the low level mechanisms of the micro-

kernel, and allows to deﬁne components and connec-

tions (between the components for communication).

CAmkES based systems use the underlying seL4 se-

Goyal, A., Garg, A., Gour, D., Shyamasundar, R. and Sivakumar, G.

Information Flow Secure CAmkES.

DOI: 10.5220/0010462602370244

In Proceedings of the 6th International Conference on Internet of Things, Big Data and Security (IoTBDS 2021), pages 237-244

ISBN: 978-989-758-504-3

237

Table 1: Information leak examples.

Case C1 C2 C3 X

1 Client 1 Helper Client 2 Conﬁdential Data

2 Bidder 1 Auctioneer Bidder 2 Bid

3 Voter 1 Voting Machine Voter 2 Vote

curity mechanism (DAC) and are thus not informa-

tion ﬂow secure. Consider an example where a GPS

tracking device of a car sends the source and desti-

nation details to a navigation server which in return

provides the directions. The navigation server might

leak the location details to an intruder. Similarly, in-

formation leak might happen in the cases listed in Ta-

ble 1 where Component 1 (C1) sends information ‘X’

to Component 2 (C2) which then sends (leaks) it to

unauthorized Component 3 (C3).

The question which arises is, can we synthe-

size information ﬂow secure, CAmkES based sys-

tems by augmenting a Mandatory Access Control

(MAC) model on the existing DAC model provided

by CAmkES? In an attempt to answer this, we aug-

ment CAmkES with Readers Writers Flow Model

(RWFM), a MAC model and coin the new framework

“Information Flow Secure CAmkES” (IFS-CAmkES)

as the systems built on it will be information ﬂow

secure. IFS-CAmkES ensures complete mediation

by RWFM monitor on every read/write access. The

main contributions of this paper are: (i) modeling

and implementation of IFS-CAmkES, (ii) implemen-

tation of some real life examples (prototypes) on IFS-

CAmkES to justify its application, (iii) performance

comparison of CAmkES and IFS-CAmkES based

systems. To the best of our knowledge, no previous

work has integrated MAC based security in CAmkES

to make informationﬂow secure, CAmkES based sys-

tems.

The rest of the paper is organised as follows: Sec-

tion 2 provides a review of the various attempts to-

wards secure operating system and a brief description

of CAmkES, relevant to this study. RWFM is dis-

cussed in Section 3. IFS-CAmkES model is presented

in Section 4. Section 5 provides its implementation

details, its application in real life examples, and per-

formance comparison of IFS-CAmkES and CAmkES

based systems. Finally, we conclude in Section 6

along with the future directions.

2 BACKGROUND

In this section, we provide a brief literature review on

efforts to build secure operating system, and brieﬂy

describe features of CAmkES.

2.1 Attempts towards Secure Operating

System

Veriﬁcation of security properties has been one of the

important objectives of the operating system veriﬁ-

cation. Early work started with UCLA Secure Unix

which mainly focused on correctness, and Provably

Secure Operating System (PSOS) which focused on

formal kernel design but the proofs were not com-

pleted by both (Walker et al., 1980) (Feiertag and

Neumann, 1979).

Linux is susceptible to trojan horse and informa-

tion ﬂow leaks as it is based on DAC. SELinux im-

plemented as a Linux security module is one of the

attempts to make Linux more secure (Loscocco and

Smalley, 2001) (Smalley et al., 2001). Proofs for ver-

ifying information ﬂow goals in SELinux, work only

at higher level kernel abstractions and not at the code

level (Guttman et al., 2005). Similarly, EROS kernel

and the MASK project proofs do not proceed to the

implementation level (Farber and Smith, 1996) (Mar-

tin et al., 2000).

Flume, a capability based operating system, con-

siders the entire Linux kernel in its TCB. Further,

non interference proof is done manually (Krohn and

Tromer, 2009). INTEGRITY-178B provides the

proof for isolation and information ﬂow but the proof

is manually connected to the source code (Richards,

2010).

To enforce information ﬂow control, HiStar im-

plements simple semantics based on object labels and

category ownership. However, there is no proof to

showthat the semantics correctly model the behaviour

of its implementation (Zeldovich et al., 2011).

seL4 is a general purpose microkernel that has an

automated and full proof of its functional correctness

from the high level speciﬁcation to the C code imple-

mentation (Klein et al., 2014). Its capability based

access control correctly models the behaviour of its

implementation. It can be conﬁgured to enforce static

information ﬂow security in the form of intransitive

non interference. In intransitive non interference if

the information is allowed to ﬂow from A to B and B

to C, then if the information ﬂows from A to C it must

ﬂow via B.

Systems built on seL4 have been formally veri-

ﬁed for providing the following security properties:

IoTBDS 2021 - 6th International Conference on Internet of Things, Big Data and Security

238

(i) Availability: An unauthorized application should

not be able to deny service in terms of the resources

(e.g. processor time and memory resources) that the

kernel manages (Klein et al., 2014). (ii) Authority

conﬁnement: Without explicit authorization, the au-

thority cannot be escalated or transferred to another

entity (Sewell et al., 2011). (iii) Integrity: With-

out authorization, an application cannot write to or

change resource state (Sewell et al., 2011). (iv) Con-

ﬁdentiality: No unauthorized read operations can be

performed (Murray et al., 2013).

seL4 is a capability based system (DAC) and sys-

tems built on it provide security only from direct ac-

cesses and not from indirect accesses. Thus, integrity

and conﬁdentiality speciﬁcations consider only direct

write and read operations respectively.

2.2 CAmkES

CAmkES is an architecture to develop embedded sys-

tems software on the top of seL4 (Kuz et al., 2007).

It abstracts over the low-level kernel mechanisms

and allows us to deﬁne components, connections be-

tween the components and interfaces through which

the components communicate over the connections.

The components can be active or passive depending

on whether it has a control thread or not. CAmkES

provides 4 types of connections:

• RPC Connection is used for making remote pro-

cedure calls via from-interface instance (of the

caller) to the to-interface instance (of the callee).

An interface may contain multiple procedures.

Components either provide (to-interface instance)

or use (from-interface instance) the interface. We

have used the terms interface and interface in-

stance interchangeably.

• RPC Call Connection is the extension of RPC

connection in which callee also replies back to the

caller. Both RPC and RPC Call are implemented

using seL4’s endpoint objects.

• Event Connection is used for providing event no-

tiﬁcations between the components. It is imple-

mented using seL4 notiﬁcation mechanism.

• Dataport Connection allows components to

communicate over shared pages.

In CAmkES, the entire system is deﬁned as an as-

sembly composition. The CAmkES parser ﬁrst gener-

ates the Abstract Syntax Tree (AST) for the CAmkES

assembly composition. There are templates for in-

terfaces and components which are then used by the

parser to produce the glue code (implementation)

which is their seL4 level code

(Klein et al., 2018).

Figure 1 is an example of CAmkES based system

consisting of three components Client 1 (C1), Helper

(H) and Client 2 (C2). C1 is connected to H via

RPC connection (h1) and H is connected to C2 via

RPC connection (h4). Interface instances have also

been shown below the arrows. From the arrow direc-

tion, we can observe, h2 is the from-interface (use)

instance and h3 is the to-interface (provide) instance.

The assembly description for the system is given in

Listing 1.

Client 1

Helper

Client 2

h1 (rpc)

h4 (rpc)

h5 h6

Figure 1: CAmkES based system.

Listing 1: Assembly description.

assembly {

composition {

component Client

1 Client1;

component Client

2 Client2;

component Help Helper;

connection seL4RPC h1(from Client1.h2, to Helper.

h3);

connection seL4RPC h4(from Helper.h5, to Client2.

h6);

}

Here, we can clearly see, information is only al-

lowed to ﬂow from C1 to H and from H to C2. But

indirectly, it can ﬂow from C1 to C2 also (which is

not speciﬁed in the composition). We use RWFM

(MAC) to prevent such indirect ﬂows in CAmkES

based systems and present IFS-CAmkES. It is impor-

tant to note that we assume, the connections in the as-

sembly composition specify the access control policy.

IFS-CAmkES considers all other ﬂows which are not

mentioned in the assembly composition as forbidden

(never allowed). Section 3 provides a brief descrip-

tion of RWFM.

3 RWFM

RWFM (Kumar and Shyamasundar, 2014) (Kumar

and Shyamasundar, 2017) takes into account the

Denning's information ﬂow control model (Denning,

1976) and suggests a natural way of deﬁning the se-

curity classes. It is a lattice based model which en-

sures both conﬁdentiality and integrity, and can thus

capture the behavior of popular information ﬂow con-

trol models like Biba (Biba, 1977) and Bell-LaPadula

More details on structure and functionality of

CAmkES can be found at: https://github.com/seL4/camkes-

tool/blob/master/docs/index.md

Information Flow Secure CAmkES

239

(Bell and LaPadula, 1973). RWFM is represented as

an eight tuple < S, O, SC, →, ⊕, ⊗, ⊤, ⊥ > where:

• S are subjects and O are objects.

• SC (security classes/labels) are deﬁned as S x 2

x 2

(owner x {set of readers} x {set of writers}).

These labels form a lattice (on permissible ﬂow

ordering) and are assigned to all the subjects and

objects by the labelling function λ. Object labels

are static while subject labels are dynamic. Owner

is required only while considering the downgrade

operation and has nothing to do with other opera-

tions. We can get ﬁrst, second and third compo-

nents of subject/object label using the functions:

Owner(), Readers() and Writers() respectively.

• → (permissible ﬂow ordering) is deﬁned as (-,⊇,

⊆). Information always ﬂows up in the lattice.

• ⊕ (join) is deﬁned as (-, ∩, ∪) and ⊗ (meet) is

deﬁned as (-, ∪, ∩).

• ⊤ (maximum label) is deﬁned as (-, φ, S) and ⊥

(minimum label) is deﬁned as (-, S, φ).

The default/initial label for a subject s is (s, S, {s})

and the objects labels are assigned based on the access

rights. Rules (determine permissible ﬂow of informa-

tion) are deﬁned for the basic operations as follows:

• Read Rule: When a subject (s) with label (s1, r1,

w1) wants to read from an object (o) with label

(s2, r2, w2) then: (i) s must belong to r2, (ii) the

label of s should be updated to the join of the la-

bels of s and o as s has gained information.

Algorithm 1 deﬁnes the read rule. It takes subject

(s) and object (o) as inputs, and returns whether

read operation is allowed or not. Once the read

operation is complete, the subject label is updated

to (s1, r1 ∩ r2, w1 ∪ w2).

Algorithm 1: Read rule.

Input: s, o

Output: Read is allowed or not

1 if s ∈ r2 then

2 return 1;

3 end

4 else

5 return 0;

6 end

• Write Rule: When a subject (s) with label (s1, r1,

w1) wants to write on an object (o) with label (s2,

r2, w2) then: (i) s must belong to w2, (ii) the la-

bel of s must be lower in the lattice than o as the

information is ﬂowing from s to o.

Algorithm 2 deﬁnes the write rule. It takes subject

(s) and object (o) as inputs, and returns whether

write operation is allowed or not.

Algorithm 2: Write rule.

Input: s, o

Output: Write is allowed or not

1 if s ∈ w2 ∧ r1 ⊇ r2 ∧ w1 ⊆ w2 then

2 return 1;

3 end

4 else

5 return 0;

6 end

RWFM helps in preventing indirect read and write

accesses in the system. The detailed model for IFS-

CAmkES is presented in Section 4.

4 INFORMATION FLOW SECURE

CAmkES MODEL

Out of the four types of connections in CAmkES

based systems, we have secured the information ﬂow

on RPC and RPC Call connections. Dataport con-

nection could not be secured because in CAmkES,

dataport access rights are frozen in page table of the

process (component), and then access is completely

controlled by the hardware (MMU) during execution.

Thus, it would not be feasible to trace the read and

write operations at the software level and use RWFM.

Moreover, dataport write access is implemented as

both read and write accesses, which is inconsistent

even with the direct access (due to the extra read ac-

cess). Event connection is used for single bit com-

munication in CAmkES, so we have not considered

it.

To secure RPC and RPC Call connections using

RWFM, we have not used shared variables to store

the RWFM labels as this may lead to inconsistency in

the labels, and the labels may be misused, resulting

in information leaks. Also, we have not changed the

existing system calls or added new system calls for

RWFM checks (rules) as this might interfere with the

underlying seL4 proofs.

We have added an another component called

RWFM Monitor at the CAmkES level. It is connected

with all other components of the system using RPC

Call connections. To prevent the information leak

from client 1 to client 2 in Figure 1, RWFM moni-

tor is used as shown in Figure 2.

The initials labels for subjects (components) and

objects (interfaces) are generated from the AST

and are fed into the RWFM monitor which stores

and manages these labels. On its interface in-

stances, RWFM monitor provides three procedures:

can

i read(), can i write() and update my label().

can i read() is same as Algorithm 1 except that it

IoTBDS 2021 - 6th International Conference on Internet of Things, Big Data and Security

240

Client 1

Helper

Client 2

RWFM Monitor

h1 (rpc)

h4 (rpc)

h5 h6

h7 (rpc call)

h10 (rpc call)

h11

h12

h13 (rpc call)

h14

h15

Figure 2: RWFM monitor.

only takes one input i.e. the object. The subject is

not needed since the monitor can infer it from the

interface used for the call. Similar argument holds

for can

i write and Algorithm 2. update my label up-

dates the subject’s label on successful read operation.

RPC and RPC Call interface templates are modiﬁed

to ensure RWFM monitor completely mediates all the

read/write requests during RPC and RPC Calls be-

tween the components. The details are presented in

Section 4.1-4.3.

Since CAmkES allows us to deﬁne components

and connections over a single system we have as-

sumed that all the components exist as virtual ma-

chines over a single system (with seL4 as hypervisor).

In general, even if the components do not exist on a

single system the communication between the sub-

components of a component might lead to informa-

tion leak and to prevent it, we can apply RWFM at the

sub-component level. Further, information leak over

the network can be prevented by applying RWFM

monitor on the access control policy of the network.

4.1 Label Generation

Label generation is done using Algorithm 3 which

takes AST as the input and generates the RWFM

labels which are then stored in the RWFM moni-

tor. Labels are generated for the components (sub-

jects) and interfaces (objects). C, I and N represent

the set of components, interfaces and connections re-

spectively in the original system (without including

RWFM monitor).

The algorithm assigns the default label to all the

components. Initially, for each interface, the parent

component is assigned as the owner, and readers and

writers set are kept empty.

For RPC connection, the parent component of the

from-interface acts as the writer and is thus added in

the writers set of both the interfaces of the connection.

The parent component of the to-interface acts as the

reader and is thus added in the readers set of both the

interfaces of the connection.

For RPC Call connection, the parent components

of both the interfaces act as readers and writers (both)

Algorithm 3: Label generation.

Input: AST

Output: Generates the RWFM labels.

1 for each component c

∈ C do

2 λ(c

) = (c

, C, {c

})

3 end

4 for each interface i

∈ I do

5 λ(i

) = (parent component, {}, {})

6 end

7 for each connection n

∈ N do

8 if n

type == rpc then

9 Readers(n

to interface) =

Readers(n

to interface) ∪

to interface parent component

Writers(n

to interface) =

Writers(n

to interface) ∪

from interface parent component

Readers(n

from interface) =

Readers(n

from interface) ∪

to interface parent component

Writers(n

from interface) =

Writers(n

from interface) ∪

from interface parent component

10 end

11 if n

type == rpc call then

12 Readers(n

to interface) =

Readers(n

to interface) ∪

to interface parent component ∪

from interface parent component

Writers(n

to interface) =

Writers(n

to interface) ∪

to interface parent component ∪

from interface parent component

Readers(n

from interface) =

Readers(n

from interface) ∪

to interface parent component ∪

from interface parent component

Writers(n

from interface) =

Writers(n

from interface) ∪

to interface parent component ∪

from interface parent component

13 end

14 end

and are thus added in both the readers and writers set

of both the interfaces of the connection.

Note that no labels are assigned to RWFM moni-

tor, its interfaces and any interface involved in com-

munication with the RWFM monitor.

The labels generated for the system shown in Fig-

ure 1 are as follows:

λ(C1) = (C1,{C1,H,C2},{C1})

λ(H) = (H,{C1,H,C2},{H})

λ(C2) = (C2,{C1,H,C2},{C2})

λ(h2) = (C1,{H},{C1})

λ(h3) = (H,{H},{C1})

λ(h5) = (H,{C2},{H})

λ(h6) = (C2,{C2},{H})

Information Flow Secure CAmkES

241

If both the connections in Figure 1 are replaced by

RPC Call connections then the labels of the interfaces

are as follows:

λ(h2) = (C1,{C1,H},{C1,H})

λ(h3) = (H,{C1,H},{C1,H})

λ(h5) = (H,{C2,H},{C2,H})

λ(h6) = (C2,{C2,H},{C2,H})

4.2 RPC Template

RPC to-interface template has seL4

Recv() system

call to read (receive) the data. It is modiﬁed to do

RWFM read check as shown in Listing 2. If it fails,

the data is not read. Otherwise, the component label

is updated once the read operation is completed.

Listing 2: RPC to-interface template.

if (!can i read(interface);)

return;

seL4

Recv();

update

my label();

RPC from-interface template has seL4 Send()

system call to send the data. It is modiﬁed to do

RWFM write check as shown in Listing 3. If it fails,

the data is not sent.

Listing 3: RPC from-interface template.

if (!can i write(interface);)

return;

seL4

Send();

Note that, can i read(), can i write() and up-

date my label() will be called as h11 can i read(),

h11

can i write() and h11 update my label() respec-

tively, by H in all its RPC to/from-interfaces imple-

mentations (seL4 code). C1 and C2 also use their own

interfaces, h8 and h14 respectively as shown in Fig-

ure 2. The argument for these procedures will be the

interface whose implementation is being done. As an

example, for h5 interface (RPC from-interface) im-

plementation, h11 can i write(h5) is used.

Now, when C1 makes an RPC to H, RWFM write

check for C1 at h2 is performed which succeeds.

RWFM read check for H at h3 also succeeds and the

label of H is updated to: λ(H) = (H,{H},{C1,H}).

Now, when H makes an RPC to C2, RWFM write

check for H at h5 fails and thus information leak (in-

direct write from C1 to C2) is avoided.

4.3 RPC Call Template

RPC Call to-interface template has seL4

Recv() sys-

tem call to receive the data and seL4

Reply() system

call to send the data (reply back to the caller). RWFM

read check is added before seL4 Recv() as shown in

Listing 4. If it fails, the data is not received. Oth-

erwise, the component label is updated once it re-

ceives. Further, RWFM write check is added before

seL4

Reply().

Listing 4: RPC Call to-interface template.

if (!can i read(interface);)

return;

seL4

Recv();

update

my label();

if (!can

i write(interface);)

return;

seL4

Reply();

RPC Call from-interface template has seL4 Call()

system call to send the data and receive the reply. It

is modiﬁed to do RWFM write check as well as read

check as in shown in Listing 5. If any of the check

fails, the data is not sent and the reply is not received.

Otherwise, the component label is updated once it re-

ceives the reply.

Listing 5: RPC Call from-interface template.

if (!can i write(interface);)

return;

if (!can

i read(interface);)

return;

seL4

Call();

update

my label();

It is important to note that the object (interface) la-

bels do not change during execution and they contain

the access control policy which is derived from the

connections (RPC/RPC Call) speciﬁed in the assem-

bly composition. Section 5 provides the implementa-

tion details.

5 IMPLEMENTATION DETAILS

We have implemented IFS-CAmkES by modifying

CAmkES 3.5.0 (built on seL4 10.0.0). We used Intel

Core i7, 8th generation machine with 16 GB of RAM

and Ubuntu 16.04 LTS operating system. We used

QEMU emulator version 2.5.0 to run CAmkES/IFS-

CAmkES.

The example stated in Figure 1 when implemented

on IFS-CAmkES, stops the indirect write by client 1

to client 2 via a helper (preserves integrity of client 2

data). Similarly, the example stated in Figure 3 when

implemented on IFS-CAmkES, stops the indirect read

by client 1 from client 2 via a helper (preserves conﬁ-

dentiality of client 2 data).

In auctioning example shown in Figure 4, an auc-

tioneer accepts the bids from bidder 1, bidder 2 and

IoTBDS 2021 - 6th International Conference on Internet of Things, Big Data and Security

242

Client 1

Helper

Client 2

h1 (rpc)

h4 (rpc)

h6 h5

Figure 3: Client 1 indirectly reads from client 2.

bidder 3. The connections from bidders to auction-

eer are used for making the bid while the connec-

tions from auctioneer to bidders are used for declaring

the result. All the connections are RPC connections.

Once the auctioneer starts getting the bids, he should

not convey those bids to other bidders, and should not

declare the result apriori. We cannot assure these con-

ditions on CAmkES while on IFS-CAmkES we can.

Once the auctioneer gets a bid, his label gets updated

in such a way, that he cannot write to other bidders.

For declaring the result, auctioneer can request the

RWFM monitor to be turned off and only then the re-

sult can be declared. Also, we can implement RWFM

at the language level (where each variable is given a

RWFM label and every operation on the variable hap-

pens as per the information ﬂow policy) and apply de-

classiﬁcation on the result variable in auctioneer in or-

der to declare the result. Similar scenario holds for the

electronic voting system (replace auctioneer by voting

machine, bidders by voters and bids by votes).

Bidder 1 Auctioneer Bidder 2

Bidder 3

h6 h5

h10

h11 h12

h13

h14

h15

h16

h17

h18

Figure 4: Auctioning.

In GPS tracking example shown in Figure 5, GPS

tracking device of a car makes an RPC Call (using

connection h1) to a navigation server with source and

destination as arguments, and navigation server re-

turns the directions. The navigation server may leak

these location details to an intruder via RPC connec-

tion h4. When implemented on IFS-CAmkES such a

leak can be avoided.

GPS Device

Navigation Server

Intruder

h1 (rpc call)

h4 (rpc)

h5 h6

Figure 5: GPS tracking.

We made a simple system consisting of only two

components and made a single RPC/RPC Call con-

nection between them and measured the number of

RPC/RPC Call communications that happened be-

tween the two components in 100 seconds (both on

CAmkES and IFS-CAmkES). The experiment was

performed multiple times to ﬁnd the average. Table

2 shows the results.

Table 2: Performance comparison (in terms of number of

RPC/RPC Call communications in 100 seconds).

RPC RPC Call

IFS-CAmkES 195872 153056

CAmkES 310615 403036

It is observed that the performance (with respect

to time) of IFS-CAmkES based system as compared

to that of CAmkES, reduces by approximately 37%

in case of RPC and by 62% in case of RPC Call.

This is due to the extra RPC Calls made by the com-

ponents (to the RWFM monitor for performing the

RWFM checks) involved in the communication. The

reduction in performance in case of RPC Call com-

munication is higher than that of RPC as the former

makes more RPC Calls to the RWFM monitor. To im-

prove the performance, we can implement RWFM at

the seL4 level where RWFM checks can be performed

inside the system calls. This would require us to redo

the seL4 correctness proofs in order to ensure that the

correctness still holds.

6 CONCLUSION AND FUTURE

SCOPE

Capability based (DAC)systems built using CAmkES

on seL4, cannot prevent the indirect accesses and

thus cannot prevent information leak in the system.

To capture the information leak, one has to imple-

ment the labelled MAC. To make CAmkES based

systems information ﬂow secure, we have proposed

a model (inspired from RWFM) which generates

initial labels based on components, RPC and RPC

Call connections (assuming the connections specify

the access control policy) speciﬁed in the CAmkES

assembly composition. All read/write accesses in

the system are completely mediated by the RWFM

monitor which also updates the label of the subject

when a read operation happens. The proposed model

has been successfully implemented and integrated in

CAmkES. We term this modiﬁed framework as Infor-

mation Flow Secure CAmkES (IFS-CAmkES) as the

systems built on it are information ﬂow secure. From

application point of view, we have implemented, real

life examples (prototypes) like auctioning, electronic

voting, GPS tracking, etc., on IFS-CAmkES. Al-

though, the performance(with respect to time) of IFS-

CAmkES based systems is less than that of CAmkES

but there is always a trade off between security and

performance.

To overcome the performance penalty and to pro-

Information Flow Secure CAmkES

243

vide information ﬂow security at the microkernel

level, we can implement RWFM at the level of seL4.

To introduce information ﬂow security restrictions at

a ﬁne grained level, language level RWFM implemen-

tation can also be considered.

REFERENCES

Bell, D. E. and LaPadula, L. J. (1973). Secure computer

systems: Mathematical foundations. Technical report,

MITRE CORP BEDFORD MA.

Biba, K. J. (1977). Integrity considerations for secure com-

puter systems. Technical report, MITRE CORP BED-

FORD MA.

Denning, D. E. (1976). A lattice model of secure informa-

tion ﬂow. Communications of the ACM, 19(5):236–

243.

Elkaduwe, D., Klein, G., and Elphinstone, K. (2008). Ver-

iﬁed protection model of the sel4 microkernel. In

Working Conference on Veriﬁed Software: Theories,

Tools, and Experiments, pages 99–114. Springer.

Farber, D. J. and Smith, J. M. (1996). State caching in the

eros kernel–implementing efﬁcient orthogonal persis-

tence in a pure capability system. In Proceedings of

7th International Workshop on Persistent Object Sys-

tems. Citeseer.

Feiertag, R. J. and Neumann, P. G. (1979). The founda-

tions of a provably secure operating system (psos). In

1979 International Workshop on Managing Require-

ments Knowledge (MARK), pages 329–334. IEEE.

Guttman, J. D., Herzog, A. L., Ramsdell, J. D., and Sko-

rupka, C. W. (2005). Verifying information ﬂow goals

in security-enhanced linux. Journal of Computer Se-

curity, 13(1):115–134.

Heiser, G., Elphinstone, K., Kuz, I., Klein, G., and Petters,

S. M. (2007). Towards trustworthy computing sys-

tems: Taking microkernels to the next level. ACM

SIGOPS Operating Systems Review, 41(4):3–11.

Jaeger, T. (2008). Operating system security. Synthesis

Lectures on Information Security, Privacy and Trust,

1(1):1–218.

Klein, G., Andronick, J., Elphinstone, K., Murray, T.,

Sewell, T., Kolanski, R., and Heiser, G. (2014). Com-

prehensive formal veriﬁcation of an os microkernel.

ACM Transactions on Computer Systems (TOCS),

32(1):2.

Klein, G., Andronick, J., Fernandez, M., Kuz, I., Murray,

T., and Heiser, G. (2018). Formally veriﬁed soft-

ware in the real world. Communications of the ACM,

61(10):68–77.

Klein, G., Elphinstone, K., Heiser, G., Andronick, J., Cock,

D., Derrin, P., Elkaduwe, D., Engelhardt, K., Kolan-

ski, R., Norrish, M., et al. (2009). sel4: Formal ver-

iﬁcation of an os kernel. In Proceedings of the ACM

SIGOPS 22nd Symposium on Operating Systems Prin-

ciples, pages 207–220. ACM.

Krohn, M. and Tromer, E. (2009). Noninterference for a

practical difc-based operating system. In 30th IEEE

Symposium on Security and Privacy, pages 61–76.

IEEE.

Kumar, N. N. and Shyamasundar, R. (2014). Real-

izing purpose-based privacy policies succinctly via

information-ﬂow labels. In Proceedings of IEEE

Fourth International Conference on Big Data and

Cloud Computing (BdCloud 2014), pages 753–760.

IEEE.

Kumar, N. N. and Shyamasundar, R. (2017). A complete

generative label model for lattice-based access con-

trol models. In International Conference on Soft-

ware Engineering and Formal Methods, pages 35–53.

Springer.

Kuz, I., Liu, Y., Gorton, I., and Heiser, G. (2007). Camkes:

A component model for secure microkernel-based

embedded systems. Journal of Systems and Software,

80(5):687–699.

Lampson, B. (2011). Technical perspective making un-

trusted code useful. Communications of the ACM,

54(11).

Loscocco, P. and Smalley, S. (2001). Integrating ﬂexible

support for security policies into the linux operating

system. In USENIX Annual Technical Conference,

FREENIX Track, pages 29–42.

Martin, W., White, P., Taylor, F., and Goldberg, A. (2000).

Formal construction of the mathematically analyzed

separation kernel. In Proceedings of Fifteenth IEEE

International Conference on Automated Software En-

gineering (ASE 2000), pages 133–141. IEEE.

Murray, T., Matichuk, D., Brassil, M., Gammie, P., Bourke,

T., Seefried, S., Lewis, C., Gao, X., and Klein, G.

(2013). sel4: from general purpose to a proof of infor-

mation ﬂow enforcement. In 2013 IEEE Symposium

on Security and Privacy, pages 415–429. IEEE.

Richards, R. J. (2010). Modeling and security analysis

of a commercial real-time operating system kernel.

In Design and Veriﬁcation of Microprocessor Sys-

tems for High-Assurance Applications, pages 301–

322. Springer.

Sewell, T., Winwood, S., Gammie, P., Murray, T., Andron-

ick, J., and Klein, G. (2011). sel4 enforces integrity.

In International Conference on Interactive Theorem

Proving, pages 325–340. Springer.

Smalley, S., Vance, C., and Salamon, W. (2001). Imple-

menting selinux as a linux security module. NAI Labs

Report, 1(43):139.

Walker, B. J., Kemmerer, R. A., and Popek, G. J. (1980).

Speciﬁcation and veriﬁcation of the ucla unix security

kernel. Communications of the ACM, 23(2):118–131.

Zeldovich, N., Boyd-Wickizer, S., Kohler, E., and

Mazi`eres, D. (2011). Making information ﬂow

explicit in histar. Communications of the ACM,

54(11):93–101.

IoTBDS 2021 - 6th International Conference on Internet of Things, Big Data and Security

244