Conference smurf::dec_mls_plus

> It is a requirement
> that the sensitivity, clearance, and information labels of the Netscape
> process are set to the maximum clearance level the account is allowed 
> to have.   

	Since the NT workstation is not a labelled system,
	the proper way to do this is to set the fields up 
	properly in the TNETRHDB record for that workstation,
	e.g.,:
		def_clearance=foo:\
		def_sl=foo:\
		def_ilb=foo:\

	The "def_" fields dictate the labels the system puts on the 
	data coming in from that host.

	[ Now, if they have different people using that particular
	Windows NT box at different times of day, each of whom might 
	have a different clearance (and therefore different process SL 
	and IL), you run into the basic "identity problem" with 
	unlabelled hosts.  People always seem to want to get something
	for nothing.

	Ask the customer how that Windows NT box is secured.  Is there
	a login function of some kind?  If yes, then tell them they
	have to add a further login function:  someone who can run
	dxtp_remote to the target MLS+ box and run dxhostmanager on
	that box and can change the identity of the host when it
	makes a new connection must "help with the login process" :-)

	Of course, I may be anticipating where no problem has yet arisen. ]

> 4.  Another problem with this is that the display host (as far as MLS+
>     is concerned) has a network SL of syslo as it's a default_single_level
>     host.  So allowing a "SECRET" window to display there is illegal.  At
>     least I think this is the problem, as dxterm chokes with a permission
>     related error if I try to set the level to anything higher than syslo.

	Right -- it is not the default_single_level host, it is something like:

	hostname.foo.fud.com:	default_spec = default_single_level:\
		def_clearance=foo:\
		def_sl=foo:\
		def_ilb=foo:
	
	As above, where "foo" is the maximum clearance the user of
	that Windows NT box is allowed to have, and you have only
	added the exceptions to the default_single_level definition
	in the particular host's TNETRHDB entry.

> 4.  I thought I'd get smart at this point and change the network labels
>     associated with the host.  So I added "SECRET" to the accreditation
>     range, which in turn allowed me to up the SL to "SECRET".  However,
>     the above setlevel command still gives me an error of:
> 
>         X Toolkit Error: Can't open display: NODE:0

	You do not need to -- and shouldn't -- use the setlevel command once
	you have the TNETRHDB record set up properly.  But the "Can't open 
	display:" is a different matter.  What X client are you running?  
	Can you rlogin/telnet in to the MLS+ and run that client with
	displaying set back to the NT box?


	P.S. Just for the record, if you were connecting as the root
	account or similarly privileged user, to do privileged functions
	via rsh, one would use epa to set the process SL, etc., context
	for the command to be executed.  But that does not apply here,
	I don't believe.
    

>   Since the NT workstation is not a labelled system,
>   the proper way to do this is to set the fields up 
>   properly in the TNETRHDB record for that workstation,
>   e.g.,:
>         def_clearance=foo:\
>         def_sl=foo:\
>         def_ilb=foo:\
    
Close, but no cigar ;-)   I tried returning the display host to a standard
default_single_level config, then poked these values in manually.  I then
couldn't connect to/from the display host at all, using any protocol.  So I
fired up dxhostmanager which complained about invalid setup values and
reset  things.  After some tinkering, I realised that I had to modify the
existing acreditation range to span U -> S  (previously I'd just added new
ranges like S -> S).  After I'd done that, dxhostmanager allowed me to set
the clearance and default SL to "Secret", and hey presto, it all worked. 
So the entry in TNETRHDB looks like:

netbsd :        default_spec = default_single_level : \
        min_sl = UNCLASSIFIED : \
        max_sl = SECRET : \
        def_clearance = SECRET : \
        def_sl = S : \
        def_ilb = SECRET : \

Now when I login from netbsd (the display host), I get an SL of SECRET
(same using rsh) and I can fire back dxterms with the same SL.  Just what I
wanted.  I also  noticed that I couldn't connect in the reverse direction
from MLS+ to netbsd unless I my MLS+ session also had an SL of secret.  I
hadn't thought about that, but understand it, and consider it to be a bonus.

Thanks for the tip on dxtp_remote too.  I didn't know that was there. 
Very handy indeed.   

I understand your other points too.  For this to work properly, each user
is going to have to be effectively tied to one workstation (or set of 
workstations) for use with a desired SL.  If a user wants to fire netscape
back from MLS+ with a different SL, they'll have to either physically move
to another seat, or perform a system management action on TNETRHDB before
logging in.   

Can MLS+ handle multiple instances of dxhostmanager running at once?

Regs,

John
 

    > can MLS+ handle multiple dxhostmanagers at once?
    
    Probably just as well as DU can support multiple people running vi on
    the same file at the same time... last one to finish wins... there is
    no file or record locking if that is what you are asking.

> there is no file or record locking if that is what you are asking.

Yes, that's what I was driving at.  I've no idea how many people will
be managing this thing, but I wanted to have the answer to the question
prepared in advance.

Thanks,

John

[Posted by WWW Notes gateway]