by Alec Muffett
Thought for the day:
Is there any benefit to installing Trusted Extensions on Solaris 10+ and then *not* installing any zones/compartments on it?
Would it work? If it did work, would any aspect of it be beneficial to operation?
Think carefully before responding. This is, after all, how RBAC ended up in Solaris.
The benefit could be that you could later on easily configure Trusted Extensions, without the need to add packages (and it seems we’re heading that way: http://www.opensolaris.org/jive/thread.jspa?threadID=35817&tstart=0 ), but I don’t see any immediate operational benefits…
It would “work” in that it wouldn’t stop working, but you wouldn’t have label functionality as such. Also, you’d have to set up tnrhdb so that any hosts or networks you wanted to talk to were mapped to admin_low, which might (at a stretch) be considered a technology complement to ipfilter.
A natural security benefit of having Trusted Extensions running, but without having label functionality set up, is that you get to have Solaris Audit set up for you with a reasonable audit_start, audit_control and audit_event config.
Finally, +1 to Bart’s comment above.
If you provided a label encodings file and setup the trusted networking (tnrhdb) you could use it as a “network guard”. This would be quite a basic “network guard” though. Most guards I’ve seen or helped deploy have at least one privileged service running at a non admin label.
So as Dave said as a complement to ipfilter to add some CIPSO knowlege in it could be useful to have a label_encodings and labeling enabled but without having any zones installed to represent those labels.
On the GUI side there are some possible benfits to running TJDS even if you have no non admin labels. In TJDS you get a trusted stripe which allows you to grapically do a password change (something that really really should be part of the standard JDS but itsn’. Much more interestingly is that you can do a “graphical su(1M)”, they way this works is it makes a whole GNOME workspace operate as it it were logged in under another user. I know of at least one customer that really wanted just this functionality for a deployment.
Correction: “it wouldn’t stop working” provided you’re using local files for user data. If you’re using LDAP, you’d still need to prod the schema to include user clearance range data – and I don’t know at this time what a non-TX Solaris box which was using the same LDAP server would make of that (although I suspect that breakage would be involved).
Update to the correction: Following a chat with my friendly local LDAP geek, it would appear (although we have yet to try it – this will be an interesting exercise for next week..) that it is possible to have an LDAP server containing data accessible to both TX and non-TX systems; it’s a matter of setting the LDAP up to be sensitive about what fields in the schema it presents to requests from which source IP addresses. Thus, the extra TX-specific fields can – we think – be kept hidden from non-TX systems.
There are several ways that Trusted Extensions can be used without any labeled zones.
As Darren mentioned, the desktop is much more secure in that you have the Trusted Path menu for secure access to devices, password changes, and role assumption. Roles windows and workspaces can’t be attacked or spied upon by untrusted clients.
The label-aware print server doesn’t require any labeled zones. It can accept requests from any label within the printers range, and ensure that the printed output is correctly labeled.
An LDAP server doesn’t require any labeled zones, either. The question Dave raised about the schema for labeling is not an issue. The schema iwas integrated into Solaris last year. We can prevent remote updates to the LDAP server, and provide read-only multilevel access via an LDAP proxy server bound to a multilevel port.
Note that Trusted Extensions packages are now integrated into OpenSolaris build 72. The TX policy can now be enabled by just typing:
# svcadm enable labeld
and rebooting.
Leave a Reply