Conference smurf::dec_mls_plus

    Just to give context for preceding: Mark Sowards called and said that a
    customer of his had ordered some Alpha 600's (VME single-board) that
    had MLS+ "factory installed" on them. I said, I wonder who factory
    installed them?  Interesting.  Anyway, he needed to know how to change
    the Encodings file without re-installing.  He's got to have some tape
    or whatever device to get the new Encodings and config files loaded in,
    and he's going to have to find out what the "factory installed" root
    password is?

    BTW, I discovered an interesting thing today:  if you run
    /tcb/bin/authck -p it will actually syntax check all the files in
    /tcb/files/auth/* -- even ones that don't "belong" there.
    
    What this means is, you can verify whether you correctly edited 
    /tcb/files/auth/r/root to change the clearance back from whatever the
    current system high string is in the current Encodings to the
    well-known "syshi" string.  Or at least verify that you didn't make
    syntax errors.
    
    So I would improve on Step 2, with:
    
    # cd /tcb/files/auth/r
    # cp root root.new
    	edit root.new
    	change:
    
    		:u_clearance=TOP\040SECRET\040A\040B\040SA\040SB\040CC:\
    
    	to:
    		:u_clearance=syshi:\
    
    # /tcb/bin/authck -p
    
    It will actually syntax check root.new, which is nice.  Then when
    you shutdown to single-user mode you can
    
    # cd /tcb/files/auth/r
    # mv root root.old
    # mv root.new root
    
    And delete root.old after you come up and are running successfully.
    

From:	US2RMC::"[email protected]" "Mark Sowards" 19-MAY-1997 05:04:56.59
To:	"'Barbara A. Thomson (ZKO3-2/X46 1-2955)'" <[email protected]>, "'[email protected]'" <smurf::bat>
CC:	"'Me@swarf'" <[email protected]>
Subj:	Results of Encodings file swap


   I'll give you a little heads up.  The reboot to single user failed after 
all the changes.  It complains about an Encodings conversion
("can't convert '8.5+GB' for encodings file") or something to that affect, 
and no part of the security labeling works.  (i.e. the mand_init fails and 
all actions dealing with the security daemon fail.)   When we tried the 
TREC procedure, the dbck functions all work, but the TREC on the root file 
system fails completely it can't convert the Encodings.
       (Now I have to say they let some Sun guy come in a re-write the 
Encodings file so it's not the same one that Curry helped them develop.) 
 However, this same file is supposed to be running on one of the other 
machines (installed from scratch).

   The reason they are willing to try so hard for this method to work is 
based on at least two factors. (1) They need Ten systems done with a very 
intricate configuration, by Wednesday.  Eight of these system (and this is 
#2) are those single board Alphas. The single board machines have no 
connections for an external tape drive.  They have multiple FDDI and 
Ethernet connections.  This makes getting the Encodings file loaded very 
difficult.  It will require multiple RIS systems to be configured because 
there are at least three (possible four) subnets in this two rack ten 
machine setup.

 It's a really weird setup there are two Alpha 600's one in the bottom of 
each rack; with two enclosed custom made boxes each containing 2  single 
board alphas.  Each pair of single board alpha has a single level FDDI 
connection between them and then the pairs are connected to the a600 in 
that rack and then the 600's are connected by an ether net.

    [ more in other notes ]

From:	SMURF::BAT          "Barbara A. Thomson ZKO3-2/X46 1-2955" 19-MAY-1997 14:09:44.88
To:	US2RMC::"[email protected]"
CC:	BAT
Subj:	RE: Results of Encodings file swap

	Mark,

	My home number is (603) 487-2974.  Please file it so that
	in the future if you are working weekends, you might be
	able to contact someone.

> It complains about an Encodings conversion
> ("can't convert '8.5+GB' for encodings file") or something to that affect, 

	That means that the Encodings file itself is incomprehensible.
	Before you reboot with a new Encodings file, you have to
	run labelcomp on the Encodings file.  (See man labelcomp).

	If you have changed the /etc/policy/macilb/config file,
	you have to use that one too.

>        (Now I have to say they let some Sun guy come in a re-write the 
> Encodings file so it's not the same one that Curry helped them develop.) 
>  However, this same file is supposed to be running on one of the other 
> machines (installed from scratch).

	"supposed to be" -- well if it truly is, then there must
	be a difference in the /etc/policy/macilb/config file.

    I spoke with Mark earlier today and he said that they were all set:
    evidently they had run labelcomp, but the Sun guy at the last minute
    decided to change markings in the /etc/policy/macilb/config to 0 and
    then they didn't subsequently run lablecomp.
    
    They should have run labelcomp, but our SecureWare code should be able
    to handle markings=0.
    
    We should file a bug report on this.

From:	SMURF::BAT          "Barbara A. Thomson ZKO3-2/X46 1-2955" 19-MAY-1997 14:09:44.88
To:	US2RMC::"[email protected]"
CC:	BAT
Subj:	RE: Results of Encodings file swap

> It complains about an Encodings conversion
> ("can't convert '8.5+GB' for encodings file") or something to that affect, 

	That means that the Encodings file itself is incomprehensible.
	Before you reboot with a new Encodings file, you have to
	run labelcomp on the Encodings file.  (See man labelcomp).

	If you have changed the /etc/policy/macilb/config file,
	you have to use that one too.

>        (Now I have to say they let some Sun guy come in a re-write the 
> Encodings file so it's not the same one that Curry helped them develop.) 
>  However, this same file is supposed to be running on one of the other 
> machines (installed from scratch).

	"supposed to be" -- well if it truly is, then there must
	be a difference in the /etc/policy/macilb/config file.

    

    I spoke with Mark earlier today and he said that they were all set:
    evidently they had run labelcomp, but the Sun guy at the last minute
    decided to change markings in the /etc/policy/macilb/config to 0 and
    then they didn't subsequently run lablecomp.
    
    They should have run labelcomp, but our SecureWare code should be able
    to handle markings=0.
    
    We should file a bug report on this.
    

    I just left you a voice mail and I thought I'd follow up with a note. 
    The change to the number of markings in the config file corrected our
    problem with the systems.  However, when doing the other systems, some
    of the extra 'help' fat fingered the TNE TMAPPINGS file, they either
    forgot to set the label or didn't set it right.  Anyway the result is
    that these two systems have TNETMAPPINGS files that cannot be chlabel'd
    or deleted or fixed.  How do we reset these files now?

    Also you said that the method Lenny was using to restore systems was
    incorrect.  Now I'm not sure if I had described it wrong or what, but
    if you could quick sketch out what was wrong then I could get Lenny
    going on the big restore of the 2100.

Mark A. Sowards
Digital Equipment Corporation
WRO Santa Clara, DTN521-4391



      Mark A. Sowards
                                      409-748-4391 DTN 521-4391 
                                            2575 Augustine Dr.
                                          Santa Clara, CA 95054
    

    Well, there are lots of things I'm learning about the differences
    between V3 and V4 through this "self-paced" instructional method,
    thanks, Mark!
    
    For one, I didn't even know there was a file called TNETMAPPINGS -
    shows you how much I've played with the CIPSO and tsix_1_1 protocols
    (zip).
    
    And for two, I didn't realize that one might have, or might want to,
    set a temporary file (which in OSF seems to be terminated with a
    :t instead of a -t as ULTRIX MLS+) created, I presume by
    create_file_securely() [sic] to a different SL than the file that it is
    an intermediate version of -- it has the same DAC protection, why not
    the same MAC?  But that's a curious observation that will require
    further investigation later [bathole alert! bathole alert!]
    
    ANYWAY, the next note is a re-posting of the bottom line instructions
    for resetting the labels on a file that has a tag that cannot be
    translated back into an IR that matches an ER in the new Encodings
    file...  I have *NOT* tried them on V4 and don't know if they will
    work.  In summary what you do is:
    
    	chlabel -NI syslo filename
    	chlabel -NS syslo filename
    	chlabel -I syslo filename
    	chlabel -S syslo filename
    
    (roughly).  If that doesn't work, then you may have to do the 
    setfstag business.  (If there is a setfstag in OSF).  If that doesn't
    work, run fsck and then trec on the file system. (See man pages).
    If that doesn't work, then we have a problem. (Bug).

         <<< SMURF::DISK$NOTES:[NOTES$LIBRARY]ULTRIX_MLS_PLUS.NOTE;1 >>>
                         -< CMW Ultrix MLS+ notesfile >-
================================================================================
Note 602.4           bad clearance or session security level              4 of 4
MKOTS3::THOMSON "Segui la tua beatitudine"           41 lines   8-APR-1994 18:44
               -< bad tags fix procedure (hit it with a hammer) >-
--------------------------------------------------------------------------------
Return-Path: minsrv::[email protected]
Date: Thu, 8 Jul 93 12:01:56 -0400
From: minsrv::[email protected] (Jonathan Fraser UEG)
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: What is the Trilogy?


Mark, Barb:

	It actually takes 3 commands to change the name labels because
of the policy rules.  Consider that both the name sl and the name
il are bad tag values because of having 'lost' the mac tag database
during the installation.  The policy rules state that when you change
either the SL or the IL, that the SL must dominate the IL.  But because
the tags are bad, the comparision of the new SL and old IL or the
old SL and the new IL will always fail.

	The solution is to first set the name IL to wildcard.  This
will always work because we don't do any dominance checks against wildcard
labels.  Then set the name SL to UNCLE.  Finally, set the name IL to UNCLE.

The commands I use are:

	find * -print | xargs chnilevel WILDCARD
	find * -print | xargs chnlevel  U
	find * -print | xargs chnilevel U


Hence, the "trilogy".


    Of course, before doing this, I run

	setfstag -a -v -i1 -t2 -i2 -t2 /dev/rrz...

to set all the inode tags to unclassified.



	Jon
    

    Mark said they were stuck - they tried the "trilogy" and it didn't work
    for them.  They ended up setting SL to syshi and rm it the file, and
    getting a copy of the file from another system.  Mark is going to check
    and see exactly what they were doing, why they couldn't get the SL to
    change.