Conference smurf::dec_mls_plus

	Phil, 
	Could you have Sue do the following:
As root, cd to /usr/bin and do an lslabel on
mail, vi, view, man, whatis, and zcat
	Verify that they all return the following for the
SL's and IL's:
         [SL]        UNCLASSIFIED
         [IL]        UNCLASSIFIED
         [Name SL]   WILDCARD
         [Name IL]   WILDCARD

	Also, check the /usr and /usr/bin directories and the
/bin link using:
lslabel -d /usr
/usr     [SL]        UNCLASSIFIED
         [IL]        UNCLASSIFIED
         [Name SL]   WILDCARD
         [Name IL]   WILDCARD
lslabel -d /usr/bin
/usr/bin     [SL]        UNCLASSIFIED
             [IL]        UNCLASSIFIED
             [Name SL]   WILDCARD
             [Name IL]   WILDCARD
# lslabel -d /bin
/bin     [SL]        UNCLASSIFIED
         [IL]        UNCLASSIFIED
         [Name SL]   WILDCARD
         [Name IL]   WILDCARD


		Thanks,
		Mark

[Posted by WWW Notes gateway]

Sue at Trusted Computer Solutions writes as below and thanks for the help.  
Any comment on her additional question?  Phil

I checked everything Mark suggested and found the problem.  The name SL for
those commands was set to something higher than the user's clearance.  So
my next question is, what about the restore process caused this to happen?
I checked the source disk that I made the tape from and the SL's are
correct on it.  I made the dump at syshi and did the restore at syshi
according to the instructions.  Also, this isn't a one time anomoly.  It's
happened everytime I've done a restore from tape.  It doesn't make sense to
me that it only happens to 24 commands but obviously there must be a
reason.  Any ideas?

Also, the SLs for the directories weren't set exactly correctly.  Most
labels were unclassified instead of wildcard.  It's easy enough to set them
correctly, but again, why aren't they preserved during the restore process.
 I can sort of understand the link between /bin and /usr/bin being messed
up since it goes across a filesystem but not /usr and /usr/bin themselves.

Again, thanks for your help.

    It is possible that restore is not restoring WILDCARD correctly.
    
    Until we investigate, try this as a workaround:
    
    add an entry in the "files file" (man 4 files, aka
    /etc/auth/system/files), after all the other /usr/bin/ entries (at end
    is okay), that looks like this:
    
    /usr/bin/*:\
            :f_mode#0555:f_owner=bin:f_group=bin:f_slevel=syslo:\
            :f_acl=WILDCARD:chkent:
    
    All files that are not in the files file explicitly otherwise, will get
    the above as its entry.
    
    If there is not an entry in the files file already, and the setting of
    the mode bits, label, etc., is not supposed to be as above, then put an
    explicit entry in the files file for it.  (Sorry for the double
    negatives.)  Put the above "wildcard" (*) entry after all the other
    /usr/bin/something entries -- so that it affects only those that have
    not been already affected.
    
    In the meantime, we'll look to see what's with restore.
    Since you found problems with only 24 files, you may prefer to put
    entries in the files file for just those files.
    
    Then after running restore, run /tcb/bin/setfiles to get the labels set
    to their proper values.  In this case, the files can be syslo or
    WILDCARD as you please (there is no need in this case for anything to
    be WILDCARD, I'm not sure why they are set up/shipped that way).

Sue says, "Thanks for the answer to my question.  It's a 
good idea.  Can't believe I
didn't think of it myself!

	Phil,
	I have just found out that the interactive version "-i" option
to the restore command is causing the name SL and IL problem. If you 
use the noninteractive "-r" option, the name SL and IL's are restored
correctly. This fails the same way on MLS V3.1A and MLS V4.0. I am 
looking into exactly why this is happening now.
	FYI - This is how I checked it out:
	1) newfs'd a scratch partition and mounted it to the /junk directory.
	2) cd /junk
	3) mkdir bin and set mode, owner, group, sl, il, name sl, name il to 
		match /usr/bin
	4) cd /junk/bin
	5) cp -p /usr/bin/mail, vi, view, zcat and set the sl, il, name sl, 
		name il on all files to match the originals.
	6) added the /junk directory to the /etc/fstab file
	7) setlevel -s syshi
	8) dump -0unf /dev/rmt0h /junk
	9) after the dump completed, cd /junk
	10) restore -rdvYf /dev/rmt0h   "This works fine, the name SL's and IL's
					are always correct."
	11) restore -idvYf /dev/rmt0h
		restore> cd bin
		restore> add zcat
		restore> extract
	12) After the interactive restore, an "lslabel /junk/bin/*" will show
		all files except zcat have correct "WILDCARD" settings for
		the name SL and name IL. zcat is incorrectly set to 
		"UNCLASSIFIED"


				Mark 
[Posted by WWW Notes gateway]

    Mark, just for your information:
    
    TRW has filed two QARs against V2 dump/restore regarding WILDCARDs and
    interactive restore (see 14024 and 14025 in the u32qar database).
    
    The reason I mention this is because it might be the same problem in
    V3/V4 and also because there is a pending security policy issue with
    interactive restore.  It was resolved (but not yet implemented) as: 
    "Only a user with the isso command auth would be able to use the -i
    switch."