assets/developer-notes/stephanie-gawroriski/2014/01/04.mkd

   1 # 2014/01/04
   2
   3 ***DISCLAIMER***: _These notes are from the defunct k8 project which_
   4 _precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26!_
   5 _The k8 project was effectively a Java SE 8 operating system and as such_
   6 _all of the notes are in the context of that scope. That project is no_
   7 _longer my goal as SquirrelJME is the spiritual successor to it._
   8
   9 _On security_
  10
  11 Existing virtual machines use a security manager which is built into the
  12 virtual machine to form a sort of self checked control of whether methods do
  13 what they normally do or fail. However, the security model is completely user
  14 space and it is possible to break out of the security restrictions, which has
  15 been done before with dire consequences. Such security mechanism in the
  16 virtual machine equates to an unlocked door which is closed, and the only
  17 thing stopping you from opening the door is because the owner told you not to.
  18 Current security which most operating systems perform are splits between the
  19 kernel and the user space. Common exploits to gain access to the kernel itself
  20 are done usually via buffer attacks, timing attacks, and general mishaps in
  21 system calls. Other exploits are possible if one were to gain access to the
  22 root account or physical medium to which they then can modify the kernel or
  23 inject modules to do their bidding.
  24
  25 The primary issue is the implementation of the virtual machine itself, the
  26 kernel requires one as does the user space. Both user space and kernel byte
  27 code (or native recompiled code) will run on the same virtual machine, however
  28 they must have separation. The kernel will run the virtual machine in
  29 supervisor mode while the user space will run that same virtual machine in
  30 user mode. In user mode, you would use a system call using whichever means is
  31 supported by the architecture to communicate with the kernel. The main issue
  32 of this is code sharing, such as user space which decides to start executing
  33 kernel code in user space as is or if the kernel decides to start executing
  34 user space methods. Both the kernel and user space will have access to the
  35 same classpath so the class data must not be exploited, otherwise the system
  36 becomes vulnerable to exploitation. The root user must be able to modify the
  37 kernel for system updates, and if someone has physical access to unencrypted
  38 storage then the kernel may be modified. Signing may work to a degree but that
  39 requires secure storage of the signing key to verify the kernel against itself
  40 with. _On code verification_
  41
  42 A major step which will have to be performed to prevent malicious activity by
  43 hand crafted byte code and native code classes, would be to run a verification
  44 step on the produced native and interpreted code. Verification of native code
  45 can be extremely complex as there are many different architectures with
  46 varying aspects. There will have to be a speed reduction to create safe native
  47 code which passes the verification stage.
  48
  49 If the code is native for a specific architecture then a verification and
  50 potential rewrite of the code may be performed. Rewriting could be done to
  51 optimize the code slightly or to set defined behavior, such as linking of ELF
  52 binaries in memory to run a program. The native code would have to be layout a
  53 specific way so that it can be easily verified while being fast and secure
  54 enough for operation.
  55
  56 In the event that the system has no capability of separation of memory pages
  57 or hardware managed privilege levels then the verification step will have to
  58 go further as everything will essentially be running in kernel mode. Since
  59 everything is in kernel mode, specially crafted code could modify the kernel
  60 and do nasty things to it. An option would be to prevent native code from
  61 running at all, however this would be slow on such systems. This way with
  62 verification before execution, the code will be able to handle being run on
  63 such a system without issue.
  64