From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
Newsgroups: comp.virus
Subject: Re: NetWare and viruses - some new results (PC)
Date: 11 Sep 92 00:01:45 GMT


 >From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
 
 Note: my  comments refer  to Netware 3.11 which Fred is using also but 
       is different from what Vessilin has at the VTC in Hamburg.
 
 >kev@inel.gov (Kevin Hemsley) writes:
 
 >> can access and what the user is allowed to do with them.  Rights
 >> Security supersedes attribute security, in that a user must first be
 >> given access to a directory, subdirectory or file before attributes
 >> can be defined for each.

 Vesselin repondeth: 

 >Correct. It is indeed so. Unfortunately, the manual says exactly the
 >opposite.
 
 I  agree with the conclusion that the structure can be confusing  *however* 
 IMHO  the  manual  (Concepts page 8) is correct.  Attributes  do  supersede 
 Rights  (more  correctly  *complement*). If the ReadOnly  bit  is  set   an 
 attribute  must  be  changed  before a file can  be  altered,  deleted,  or 
 renamed irreguardless of what rights a user has (including Supervisor).
 
 If you are considering action based on what must be granted to gain access, 
 then the  rights  must  *precede* any test of the  attributes  but  do  not 
 *supersede*  the  attributes. Rights (Supervisor, Modify) can  be  used  to 
 change attributes but not to bypass them.
 
 One  of  the  things  I feel to have been fortunate  in  my  education  was 
 exposure  to  such  things  as Set  Theory,  Boolean  Algebra,  and  Linear 
 Programming  at a tender age, courses that I fear are rarely taught  to  CS 
 majors  nowadays. The concepts of rights and attributes are best  expressed 
 as Boolean relationships as is attempted to be rendered into ASCII below:
 
 Possibly  the best way to look at the difference is that RIGHTS state  what 
 the user is permitted to do to a file or a directory. ATTRIBUTES state what 
 is  *not*  permitted  to  be done to a file  or  directory:  RIGHTS  allow, 
 ATTRIBUTES  disallow.  RIGHTS refer to the user, ATTRIBUTES  refer  to  the 
 object  (oops  8*).  In  Boolean  terms  you  must  be  allowed  and  *not* 
 disallowed.
 
 Thus for a particular file (say MAPMEM.COM), the user rights NOT SUPERVISOR 
 AND  NOT  ACCESS  AND NOT MODIFY ANDed with  the  file  attribute  READONLY 
 *should*  protect  MAPMEM.COM  from direct infection  (says  nothing  about 
 companion or path viruses, just that this particular copy of MAPMEM.COM  is 
 protected). 
 
 In contrast, while contextually NOT SUPERVISOR AND NOT ACCESS AND NOT WRITE
 has  the same protection for MAPMEM.COM, the protection is extended to  all 
 files  in  the directory. In short attributes protect a file  or  directory 
 from  everybody while a lack of rights protects the file or directory  from 
 the user.
 
 Generally  though, rights have more power than attribute since  either  the 
 SUPERVISOR  or  MODIFY right can be used to change any  attribute  *except* 
 one: once the EXECUTEONLY attribute is set, it cannot be changed, the  file 
 can  only be deleted and restored from a fresh copy. This is  obviously  an 
 attempt  by  Novell to protect an executable even from an  infected  client 
 with SUPERVISOR right.
 
 However,  despite  such powerful macros as FLAG RO *.* /S,  attributes  are 
 falling out of use for two reasons:
 
 1)   Unlike  RIGHTS which are enforced at the server level, attributes  are 
      enforced by the client shell (hence the PC - MacIntosh difference) and
      may be overridden by directed client software (some viruses do already
      - I have some testing planned).
 
 2)   As  noted by Dr. Cohen, the logic can be puzzling particularly if  all 
      that  one has to go on is the CONCEPTS volume and  conventional  (even 
      UNIX 8*) data protection experience. Ignorance is curable.
 
 Given  all of the above, once the proper logical understanding is  made  of 
 rights  and  attributes,  I  see  no  difficulty  in  understanding   their 
 implications,  not do I find any problem with the documentation other  than 
 it  is  more  of an encyclopedia than a tutorial. In other  words,  if  you 
 already know the answer, it is useful. If not, hire a CNE. (or CNA now).
 
 More importantly to the non-technical manager who has been receiving  these 
 contradictory  reports  via  Virus-L  (have had a  few  calls  already),  a 
 *properly*  set-up  Novell  LAN not IMHO a flawed system that  is  an  open 
 invitation  to  viruses.  In  fact  it is  less  likely  to  experience  an 
 uncontrolled virus infection than a stand-alone PC even though the  Netware 
 security is not directed at protection from malicious software.
 
 Again  IMHO LANs that are at risk (that is *all* that are  not  single-user 
 like  mine  8*) need a properly layered mix of Novell,  third  party  NLMs, 
 exception reporting, and TSRs to achieve a high degree of confidence but it 
 *can* be done.
 
 Further,  being in a nasty mood, I'll reiterate that IMNSHO *only*  client-
 server  systems supporing login scripting such as Netware can  be  properly 
 protected  from infected clients. Peer-peer systems that do not  are  virus 
 havens.
 
 					Warmly,
 
      						Padgett
 
 ps  don't  forget  that the above comments refer to  the  current  product, 
      Netware 3.11 & may not apply to older/other versions