Kernel mein (as in hindi) Kernel

Dear Reader,

I've backlogged quite a bit on my blogs and hope to complete them in the next couple of weeks. Every time I sit to complete a blog, I'm flooded with topics for a new blog!! This blog is technical and addresses issues in data security.

I will be updating this blog later with some code snippets and samples. But until then, I've only penned my thoughts.

Let me know what you think in the comments section.

Regards,
Jyothin

-----------------------------------------------------------------------------------------------------------------

Introduction

Mobile device security is getting the much needed push by technologist to provide a secure mobile experience to users. Whether it is financial transactions, personal data security, photo security, device security, protection from viruses, etc., it is imperative that one thinks about how secure their lives are with mobile devices becoming extensions of an individuals personality.

There are numerous ways in which a device can be made secure; DaaS (Desktop as a Service), ACL (Access Control Lists), encrypted data transmission, etc. and some of them go that extra mile to ensure device security; double encryption, remote wipes and auto-locks, mobile ID authentication mechanisms, isolated special subnets for mobiles, signal range control, etc.

The Probability of 'Safe'-keeping

In a non digital scenario, when an average person wants to safe keep items that are dear to them, the most likely way to do it is to install a safe in their house and secure it with a password or number lock. Sounds fine and work pretty well in most cases. Lets call this safe the outer safe.

Lets for a moment assume that the probability of someone breaking into the safe and stealing your items is x. Hence the probability of someone accessing your data is x.

Lets also assume that, you feel that x is not small enough for you. So you decide to put another mini-safe within the outer safe and also secure it with a password or number lock or any other better locking mechanism. Lets call this mini-safe the inner safe. Now the probability of someone stealing your outer safe is still x but the probability of someone accessing your data is not x.

Assume again that the probability of someone managing to break open the inner safe is y. By theory of probability the probability of someone accessing your items is x times y.

With only an outer safe:
P[break opening the safe] = x
P[accessing your items] = x

With an inner safe inside the outer safe:
P[break opening the outer safe] = x
P[break opening the inner safe] = y
P[accessing your items] = x * y

For any values you choose for x and y; P[accessing your items], when there is an inner safe is less than P[accessing your items] when there is only an outer safe.

For example, if x = 0.5 and y = 0.5,
With only an outer safe:
P[break opening the safe] = 0.5
P[accessing your items]   = 0.5

With an inner safe inside the outer safe:
P[break opening the outer safe] = 0.5
P[break opening the inner safe] = 0.5
P[accessing your items]         = 0.5 * 0.5 = 0.25

What's a 'Safe' in the Digital World?

A safe is an fixed sized enclosed space that stores your items and requires a key to unlock. In the digital world your items are data (bytes of information) stored in a fixed sized memory and a safe would be a means of protecting that memory space.

In operating systems, especially operating systems based on the Linux kernel, a user typically runs processes/tasks or reads/writes to memory in user space. The operating system itself runs in protected mode in kernel space. A user requests the operating system for access to resources in kernel space. Resources could be I/O devices, protected memory space, processor resources, etc. Requests are usually made using drivers which in turn use IOCTLs to provide custom functionality.

A user cannot access kernel space resources directly. So, in a way, one can think of everything in kernel space as being put in a safe (the outer safe) and access is restricted to users who have the root password OR via drivers. If there are no drivers then the only way to access resources in the safe is by the root.

For the purposes of this discussion, lets assume the resource we are interested in accessing is data in a fixed sized memory space in kernel space. Using the same idea described in the previous section if we can install an inner safe within the outer safe, in this case a kernel within a kernel, the probability of accessing data within the inner kernel is reduced and hence a means of increased security for the data. A protected mode within a protected mode!!

Of course, we would need a means of accessing the inner safe from the outer safe by means of a driver. In a mobile device, everything is stored as bytes of data and drivers can be loaded/unloaded as required thus adding another layer of security. Further, there is nothing stopping the driver from 'loading' the inner kernel at run-time. So the driver only loads the inner kernel with required, accesses the protected data in the inner kernel and shuts it down when done. The inner kernel is modified for every modify/write of data into its protected memory. So, in affect the inner safe does not exist unless it is required to access the data!

It should be possible to create multiple such independent inner safes to protect different items and load them at run time.

Isn't virtualization the same thing?

No. Simplistically put virtualization techniques typically allow one to virtualize hardware resources in order to run different operating systems on the same hardware so that, you can install and run different software applications on the same hardware and hardware resources, and everything is managed by the virtualization environment.

The aim of a kernel within a kernel is to provide an added level of security to data which is already running in protected mode.

Can I put another Safe inside the Inner Safe?

Sure you can, but the marginal advantage of having more than two safes would eventually diminish to 0 unless the locking mechanism at each inner safe is completely different from the other safes. Essentially making it difficult for anyone to break open each safe (as the locking mechanism at each safe is different).

READ vs. READ, MODIFY, WRITE

Breaking into an inner safe will allow one to read the contents of the inner safe. Modifying the contents is a totally different activity. However, once read the data is compromised. In case of an inner kernel, breaking into an inner kernel will potentially allow one to read the contents of its protected memory, modify it and write back. READ-MODIFY-WRITE, is easier in the digital world.

Moreover, creating the inner kernel would require one to hard-code certain kernel data that is unique to that version of the inner kernel and also ensure that that uniqueness persists even when the kernel is shutdown.

An Inner Safe cannot be duplicated but an Inner Kernel can...

Hmm... I guess it can.

Conclusion

I'm no expert on data security nor on Linux Kernel Internals and unless I make an attempt to write a driver to access an internal kernel, the intricacies and challenges involved in implementing it are beyond my own understanding.

If you are really paranoid about securing your data, take a space flight to the moon, find an undisclosed uninhabited area, dig a hole, bury it, and don't tell anyone.