SubOS-enabled Operating Systems

  SubOS is a process-specific protection mechanism, a more extensive discussion on SubOS can be found in [12]. Under SubOS any application (e.g. ghostscript, perl, etc.) that might operate on possibly malicious objects (e.g. postscript files, perl scripts, etc.) behaves like an operating system, restricting their accesses to system resources. We are going to call these applications SubOS processes, or sub-processes in the rest of this paper. Figures and demonstrate the difference between a regular and a SubOS-enabled operating system. The access rights for that object are determined by a sub-user id that is assigned to it when it is first accepted by the system. The sub-user id is a similar notion to the regular UNIX user id's. In UNIX the user id determines what resources the user is allowed to have access to, in SubOS the sub-user id determines what resources the object is allowed to have access to. The advantage of using sub-user id's is that we can identify individual objects with an immutable tag, which allows us to bind a set of access rights to them. This allows for finer grain per-object access control, as opposed to per-user access control.

  

Figure: User applications executing on an operating system maintain the user privileges, allowing them almost full access to the underlying operating system.

  

Figure: Under SubOS enabled operating systems user applications that ``touch'' possibly malicious objects no longer maintain the user access rights, and only get restricted access to the underlying system.

The idea becomes clear if we look at the example shown in Figure . Let us assume that our untrusted object is a postscript file foo.ps. To that object we have associated a sub-user id, as we will discuss in Section . Foo.ps initially is an inactive object in the file system. While it remains inactive it poses no threat to the security of the system. However the moment gs(1) opens it, and starts executing its code, foo.ps becomes active, and automatically a possible danger to the system. To contain this threat, the applications that open untrusted objects, inherit the sub-user id of that objects, and are hereafter bound to the permissions and privileges dictated by that sub-user id.

There is a strong analogy here to the standard UNIX setuid(2) mechanism. When a suitably-marked file is executed, the process acquires the access rights of the owner. With SubOS, suitably-marked processes acquire the access rights of the owner of the files that they open. In this case, of course, the new rights are never greater than those the process had before.

  

Figure: In the left part of the Figure we see an object, in this case a postscript file foo.ps, with its associated sub-user id. The moment the ghostscript application opens file Foo.ps, it turns into a SubOS process and it inherits the sub-user id that was associated with the untrusted object. From now on, this process has the permissions and privileges associated with this sub-user id.

The advantages of our approach become apparent if we consider the alternative methods of ensuring that a malicious object does not harm the system. Again using our postscript example we can execute foo.ps inside a safe interpreter that will limit its access to the underlying file system. There are however a number of examples on how relying on safe languages fails [11]. We could execute the postscript interpreter inside a sandbox using chroot(2), but this will prohibit it from accessing font files that it might need. Finally we could read the postscript code and make sure that it does not include any malicious commands, but this is impractical.

Our method provides transparency to the user and increased security since every data object has its access rights bound to its identity, preventing it from harming the system.