By Stephen on Mar 31, 2006
I promised some screenshots quite a while ago. So here we go. Please note that we are still in development and these images may not represent the final product.
Firstly, lets look at a the whole screen of a Multi-Label Trusted JDS session.
You can see that there are a number of new elements in the desktop and a number of differences in existing JDS components. For starters the window manager now labels every window on the desktop with its security label. Labels are given to all applications and data objects on the system. It is the definition of these labels and their relationship to each other that defines part of the Mandatory Access Control (MAC) policy of the system. Label names are arbitrary and those seen here are only an example. Colours are associated with labels for easy identification and again these colours can be arbitrarily defined.
It is important to understand that applications running at a particular security label are restricted from interacting with applications and data at other security labels. That is, filesystem (including removable media and NFS) access, interclient network communication, copy and paste and drag and drop restrictions are all enforced by the Solaris kernel and the Trusted Computing Base (TCB) desktop applications.
Users are given a label range to operate within and they can choose their clearance from within this range when they log in. This range is also clamped by the allowed label range of the system they are logging into. For example, if the system is defined to have a single label of "Top Secret" and my user's label range has a highest clearance of "Secret" (where "Top Secret" is a higher classification than "Secret"), the box will simply not let me log in.
Once logged in the user can select a label (from their login label range) to be associated with each of their virtual workspaces. This means that all applications launched from each workspace will be restricted to operating at the security label of that workspace.
You can see that each workspace has a colour which defines its security label and the tooltips indicate the name of the labels.
Here the desktop task list also shows the labels of the currently running application windows.
Some windows will be labeled as "Trusted Path". When users see these windows they know that they are from Trusted applications in the TCB. For example a change password dialog will be labeled "Trusted Path" so that unprivileged applications cannot spoof the user into providing their passwords. Another example of a "Trusted Path" window is the selection manager confirmation dialog. You can see examples of these in later screenshots. Windows can also be labeled as "Trusted Path" if the user has a special Administration label defined in their label range, but this is not usually the case for normal users. I only mention this here to explain why gimp is labeled as "Trusted Path" in a one of the screenshots below. I was logged in with this special Admin label clearance so I could take the screenshots
One of the new UI components of Trusted JDS is the Trusted Stripe. Forgive the blurry user names in the following shots.
This TCB component is responsible for a number of things. From left to right the UI elements are: 1) The Trust indicator. This will show a shield icon if the currently focused window is "Trusted". See the second shot of the stripe below. 2) the Trusted Path menu with access to a change password GUI, device allocation and administration and a window label query tool. 3) The User id/Role id of the current workspace. This is a drop down menu which allows the login user to assume any one of the roles assigned to that user. The user can switch roles simply by selecting the role in the list and authenticating. Switching back to their own user id is just as simple, by selecting their user id from the list. Once a role has been assumed for a workspace all applications launched in that workspace are launched as that role. This is how Solaris Role Based Access Control (RBAC) is exposed in Trusted JDS. 4) This is a label indicator for the current workspace and finally 5) this is a label indicator for the currently focused window.
This shot of the stripe shows the currently focused window to be Trusted and the trust indicator is visible.
One of the reasons you want to use a multi-label Trusted desktop is to get away from the situation you are in now, where you have N desktop systems (One for each security context) sitting at your desk. These take up space, waste power and are hooked up to separate disjointed networks just to keep applications ad data compartmentalised.
Another reason for using a multi-label capable desktop is that sometimes you do want to reclassify files or data objects. With the "multiple systems at your desk" scenario you would need to use SneakerNet to transfer the data between machines using whatever external media is avilable. With Trusted JDS this is as simple as copy and paste or drag and drop. Of course users need to have the appropriate authorisation to complete these transfers. Have a look at these two screen shots.
This first shot shows the selection manager intercepting a data copy and paste from one label (CONFIDENTIAL : RESTRICTED) to another label (CONFIDENTIAL : INTERNAL USE ONLY). As the source label dominates the destination label, this is an attempt to downgrade the data. In this case the user is not authorised for this operation and there is no way to complete the transfer.
Now look at the second example.
This shot shows a transaction in the other direction which constitutes an information upgrade. Upgrading information is generally considered to be less risky than downgrading and this user is authorised to perform these transactions. In this case the user can accept the transfer to reclassify the data or cancel the transaction. All transactions intercepted by the selection manager will be auto canceled after a timeout period.
This same mechanism is used for cut/copy & paste (or drag and drop) of files from a folder at one label to another folder at a different label.
Sometimes it is necessary for two people to confirm a particular transaction. In the example above where this user was not authorised to downgrade information, perhaps he/she has a role assigned to him/her that does have this authorisation, but he/she does not have the information necessary to authenticate for this role. That person may need the cooperation of another person who can authenticate for that role. This maybe someone with a higher authority or a even a person who cannot assume the role (but knows how to authenticate for it) and so you have implemented a "Two Man Rule" for this type of transaction.
Well thats quite a long post and I probably haven't explained it all very well (I am an engineer after all), but there you go.
I hope you have at least some idea of what I'm talking about.