Dave's Bit Bucket

Friday February 15, 2008

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...

(2008-02-15 10:30:00.0) Permalink Comments [0]

Tuesday February 12, 2008

"Plans to sever Internet connectivity for media pirates"

This is thought-provoking, and I think the Internet Service Providers' Association have it spot-on with their comment on the article.

Specifically, I'm wondering how easy, putting a notional Black Hat on, it would be to prevent an ISP from finding out what I was downloading.

Torrent technology isn't something I'm intimately familiar with (not having used it), but I would hope that it incorporates something akin to IM's OTR.

If it doesn't, I'd need to VPN into some bastion host outside my ISP's remit - ideally getting there using Tor or something very much like it - and run whatever Torrent peer app from there (where "there" equals "a country which doesn't have Internet piracy laws").

If the bastion was used for things other than piracy of copyrighted media, an ISP would have a major job on its hands to prove that the heap of ciphertext traversing their infrastructure was the latest Hollywood blockbuster rather than, say, the latest .iso of Solaris 10.

Also, I expect the test case will happen shortly after any new law in this area is enacted; if I can prove I have paid my TV licence fee continually since it started showing in its current format, would it still be illegal for me to download, via a Torrent system, what is supposedly the third-most popular TV series on the P2P networks; "Top Gear"?

(2008-02-12 08:53:26.0) Permalink Comments [1]