Two possibilities might motivate creation of an apartment:
An orthogonal issue is the safety and privacy for the tenant. The tenant code or its actions may be proprietary. Some agent outside the machine, such as the owner of the tenant code, may want to veil or defend the apartment. This will require attention of the apartment creator which must be trusted by the agent. Some degree of defense of the apartment will already be required to support the interests of the apartment creator. This will in turn require some degree of tamper resistance if the tenant does not entirely trust the machine operator. Apple provides the bundle as a weak form of protection against the user. Perhaps a manufacturer can convince some that there is a private key known only to apartment creators in the systems he delivers and that any program encrypted to public key x can be decoded only by such creators and such programs will be operated with full veiling and defense in place. We postpone further consideration of tenant interests for now.
The exigent issue for the apartment design is what initial capabilities should be available in the apartment to the tenant code. There are several requirements that must be juggled here:
The creator of these apartments is in a strategic position to grant these initial capabilities so as to provide security for the system that is not available in conventional systems. The apartment creator is able to build apartments with the following kinds of attributes, subject to the combined restrictions by the system operator and tenant.
It seems strategic for a tenant to not have access to local facilities that it does not need. This tactic allows deletions of local facilities in more situations where no critical applications rely on them.
Some apartments will come with access to the outside world, but this is known to the apartment creator and this fact continues to be available to the operator. Perhaps access it intermittent as controlled by the operator and that is known to both. Perhaps the channel to the world is one way.
Within your apartment you can establish sub apartments suitable for applications of your choice. The logic of the sub-apartment protects you from some malfeasance of the application while the larger private apartment protects the employer’s agents from even your blunders in empowering the applications of your choice.
Alternatively you might buy the hardware with a security kernel that lets you create apartments for work purposes. If you are a consultant you might create an apartment for each client that wants its own secure presence in your computer. This would help you keep proprietary information of clients separate. These apartments would be like those designed for DRM except that they might include the ability to establish sub-apartments for software vendors.
I suppose that this is the state of the deployed art. Note that it takes no special authority to create a new apartment and invite a new guest. Package managers today typically ask for root privilege and tell you little of what they use that for.
A tenant designed for such an apartment will typically deliver a port (capability) via which the machine operator and his programs can communicate with the tenant. Damage to the operator occurs only when sensitive capabilities are passed to the tenant code, or capabilities whose invocation might damage the operator, are passed to the tenant. Some tenants will have no channel out thru which to exfiltrate secrets, unless such channels are explicitly passed to the tenant. The machine operator retains the authority to cancel and thus expel a tenant and reclaim the space initially used. Durability of tenant function is always limited this this potential action. Perhaps the operator can can visibly abdicate his authority to evict a tenant.
I claim that all of the logic described above can be provided by less than a megabyte of code, or could have been when hardware was simpler than it is now.