I am no longer 100% Linux.

Something which I recently did – as of May 17 to be precise – was, to install Windows 10 on a Virtual Machine. This is not to be confused with the use of ‘Wine’, because an Emulator is not the same thing as a VM. When using a VM, the ISO File authored by Microsoft, in this case, needs to be provided, so that Genuine Windows can install itself, in an isolated environment, that behaves exactly as a regular computer would behave, by itself.

AFAIK, this is a perfectly legal thing to do. And my perception of that is amplified, by the fact that within Windows 10, I was able to go through the Windows Store, to purchase the activation for that instance. If it was illegal, then I should have obtained a message to the effect.

Also, when Windows software runs on a VM, certain hardware can be ‘fed through’ to this ‘Guest System’, such as specific USB Devices. But, when they are, Windows relies on its own device-drivers, to be able to use them, or, on vendor-supplied device drivers. What this means is that at the raw binary level, the VM itself is forwarding the data, without attempting to reparse or analyze it in any way.

Screenshot_20200522_153241

I can still get error messages, but so far, those have only come as a result of silly user errors, that would have produced the same error messages had Windows been running natively.

And, because the Guest System is genuinely Windows, I can no longer say that I have zero Windows instances running. It’s just that, for now, the Windows instance I have running, resides inside a VM and doesn’t own ‘the Real Computer’ – aka the ‘Host System’.

What I do notice is the fact, that some of the errors which I made, were due to not having used Windows for a long time.

Dirk

 

Android Permissions Control

One fact which I had written about before, was that Android differs from Linux, in that under Android, every installed app has its own username. Also, because different users installed a different set of apps in different order, the UID – an actual number – for any given username will be different from one device to the next. And then I also wrote, that a username belonging to a group or not so, can be used to manage access control, just like under Linux.

There is a reason for which things are not so simple with Android. Most Android apps are written in a language named “Dalvik”, the source code of which has syntax identical to “Java”, and which must be compiled into “Bytecode”. The bytecode in turn runs on a bytecode interpreter, which is also referred to as a Virtual Machine.

The reason for which this affects permissions, is because as far as the kernel can see, this VM itself runs under one username. This is similar to how a Java VM would run under one username. And so a much more complex security model is put in place by the VM itself, because presumably this VM’s username has far-reaching capabilities on the device.

The actual use of groups to control access under Android is simpler, and applies at first glance to processes which have been compiled with the ‘NDK’ – with the “Native Development Kit” – and which therefore run directly, say from C++ source code.

Further, the Dalvik VM is capable of reading the permissions of actual files, and is capable of applying its own security model, in a way that takes the permission bits into account, that have been assigned to the files by the Linux kernel. So for most purposes, the security model on the VM is more important than the actual permission bits, as assigned and implemented by the kernel, because most Android source code is effectively written in a Java-like language.

Dirk