Labelled Desktop Lockdown, Part 1: Trusted JDS

While Trusted JDS is a reasonably well-featured desktop (although there are some new features which we're expecting to deliver in Update 5), some customers are likely to want to use TX as "the ultimate, luxury KVM switch" from the perspective of allowing access to very few intrinsic capabilities. I've been on something of a voyage of discovery in my lab for a couple of days, figuring out how all this works; I'd like to give a very big tip of the hat to Joerg Barfuth, for his assistance with a number of issues I came across.

I cut my Unix GUI teeth nigh on a decade and a half ago on twm, moved (briefly) to mwm, settled happily into CDE on Solaris, and fvwm2 on Linux, before going significantly Aqua when Apple went OS X. I'd hardly used Gnome at all, until I was asked to strip features out of Trusted JDS for a demo we're showing at an exhibition, next month. So, here we go...

If you've used a Trusted desktop before (and if you haven't, and have the time, download Solaris 10 and give it a go), you might have noticed that the X server in such an environment is a fascinating thing; different elements of the screen as you see it, are rendered by different parts of the platform.

Specifically, in Trusted JDS, the Launch menu, toolbar, trusted screenstripe (which gives you the trusted shield, the password change tool, label builder, graphical role changer, object label display and, privilege permitting, device allocator) and screensaver are all rendered by Trusted Path (in other words, the Global Zone). The desktop workspace, icons and any user apps which are started up, are rendered by the various labelled non-global zones.

The way this works, is that the X server uses multi-level ports (see /etc/security/tsol/tnzonecfg, and you'll see the familiar 6000-range ports included) to move X data between non-global zones and Trusted Path. When a workspace is opened at a label, or a label is changed by the label builder, the X server uses a TX-specific zone_enter() call to implicitly log the user into the zone so that they can do work there; a major way in which zone_enter() differs from zlogin, is that a zone responding to a zone_enter() trusts Trusted Path to have appropriately authenticated the user, so a zone_enter() call doesn't traverse the non-global zone's PAM stack.

So - as the Launch tool runs at Trusted Path we need to remove access to apps from it, there, and as the workspace runs in the labelled zone, we need to restrict access to apps, from there.

It's always best to do this as a scratch user. Another point worth being aware of, is that a user has a home directory on Trusted Path and in every zone corresponding to a label within their clearance range; some configuration steps will need iterating across zones.

Anyway, here's where Joerg introduced me to the delights of gconf-editor. Launch it from a terminal running at a label in a non-global zone.

Under apps/nautilus/desktop, are the tunables (ending in '=icon_visible") which can prevent the display of "This Computer", "Documents", "Network Places" and "Trash"; removal of "StarOffice" and "Help" is most readily accomplished by highlighting the icons and selecting "Move to Trash".

Once you have a workspace devoid of any icons, go to desktop/gnome/lockdown and enable whichever lockdown options you need, with the exception of disable_save_to_disk (otherwise, you won't be able to do the next bit :-) ).

Using the terminal you launched gconf-edit from (as you may not want to be able to launch a terminal in your new profile :-) ):

$ gconftool-2 --direct --config-source xml::$HOME/.gconf --dump /desktop/gnome/lockdown > mylockdown.xml

$ gconftool-2 --direct --config-source xml::$HOME/.gconf --dump /apps/nautilus/desktop > mybackdrop.xml

Log out, log back in as a user with appropriate privilege on Trusted Path, and cp /zone/<zonename>/root/export/home/<username>/mylockdown.xml and mybackdrop.xml back to somewhere on Trusted Path which labelled zones loopback-mount; hand-edit mylockdown.xml if you wish, to add:

<entry>
<key>disable_save_to_disk</key>
<value>
<bool>true</bool>
</value>
</entry>

...between the similarly-formatted entity for "disable_printing" and the one for "restrict_application_launching".

As the Launch tool runs on Trusted Path, mylockdown.xml only needs to be imported into gconf once; at Trusted Path, do:

# gconftool-2 --direct --config-source xml::/etc/gconf/gconf.xml.mandatory --load mylockdown.xml

...and then, at each label within the user's clearance range, connect to the appropriate non-global zones (via zlogin, label change, take your pick) and:

# gconftool-2 --direct --config-source xml::/etc/gconf/gconf.xml.mandatory --load $WHEREVER/mylockdown.xml

# gconftool-2 --direct --config-source xml::/etc/gconf/gconf.xml.mandatory --load $WHEREVER/mybackdrop.xml

Note that this assumes you are looking to lock the desktop down for all users, which is normally the case; I'll re-edit this posting shortly, to indicate how different degrees of lockdown can be achieved for different users or roles, at a given label. Of course, if you wish to vary the available applications on a per-label basis for the same user, you just need to create multiple lockdown and backdrop profiles as appropriate, and deploy the relevant profiles at the relevant labels, as above.

Part 2, if all goes to plan, will cover what you can do to achieve the same ends, with Trusted CDE; this will also (very likely) act as a "belt and braces" approach to what I've described above...

Comments:

for CDE, you use the same mechanism as in TSOL8, that is, the /etc/security/exec_attr, prof_attr and /etc/user_attr files. In Trusted JDS, the 'act' keyword is ignored in exec_attr effectively unlocking all 'CDE actions.'

Posted by guest on February 18, 2009 at 09:40 AM GMT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

davew

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today