Re: More Rconsole stuff

From: Randy Richardson (randy@INTER-CORPORATE.COM)
Date: Mon Oct 12 1998 - 12:27:11 PDT

  • Next message: Area de Seguridad en Computo: "Computer Security Day (DISC 98) in Mexico"

    > > > The problem here is that Inetcfg saves the Rconsole password to SYS:ETC
    > > > in a file named Netinfo.cfg. All users have full read access to this
    > > > directory so anyone with a valid account can view the Rconsole password.
    > > > Given Simple Nomad's post, even if you cut and paste in order to ensure
    > > > that the password is encrypted, it is still extremely vulnerable.
    > >
    > >         That's not correct.  By default, users don't have access to SYS:ETC.  If you
    > > grant them access here, then you're asking for trouble because the only modules
    > > that need access to this directory are the NLMs (NetWare Loadable Modules) that
    > > run on the server.
    [Snip]
    >
    > SYS:ETC being world readable occurs once you install one or more IP
    > services on the system. My understanding is that the Web server, NFS,
    > etc. needs to have this directory world readable. If you are not running
    > any of the IP stuff, it is okay to take rights away from this directory.
    
            That's incorrect (although you are correct in that it's okay to revoke the
    rights from this directory).  The applications that need access to SYS:ETC
    don't grant "world" (or in NetWare speak "[Public]") access to this directory,
    rather they usually create an Object (usually of type "User") somewhere in the
    NDS tree (usually in the same context as the associated server object) which is
    granted the required access to various directories including SYS:ETC.  A good
    installation utility informs the installer/administrator of these changes.
    
            Station restrictions can be applied by administrators to these objects (and
    probably should be if the application's installation procedure failed to do
    this) so the object can only login from the node (MAC) address of the server
    itself.  This prevents a user/hacker from logging in as that object from a
    workstation internally or externally (e.g., over the internet).
    
    > Simply deleting the services does not seem to remove the world readable
    > flag.
    
            The presence of software is never tied to rights in this way.  If you remove
    the directory where the software was installed (and rights were granted), then
    the removal of the directory would cause the rights to disappear.
    
            Some software may come with removal utilities that remove the file and
    directory rights its sister/brother (gotta be politically correct!) install
    utility set up in the first place, but given the nature of shared directories
    where end-users sometimes save files that don't belong there (e.g., a
    WordPerfect document in the work directory for a small database) is the very
    reason many of these removal utilities aren't created or only deal with the
    directories the application was installed in (we rely on qualified network
    administrators to take care of the rest).
    
            For security reasons, the network administrator should be removing software
    and not relying on an automated software tool when file/directory rights are or
    may be involved.  Of course, from the workstation point of view, very limited
    security is available (just go to any high school and you can find a few kids
    who know how to bypass the login prompt for Windows 95 and NT Workstation - I
    suspect they learn from the internet), so automated removal utilities can be
    very helpful.
    
    > On a lighter note, this directory also contains a copy of console.log,
    > the log file generated by console.nlm. Not a good file to be in plain
    > view either.
    
            SYS:ETC is an important directory, almost as important as SYS:SYSTEM.  If your
    users do have full access to SYS:ETC, remember that you can apply IRFs
    (Inhereted Rights Masks) at both the directory and the file level.
    
            Of course, users normally don't even know that the SYS:ETC directory exists
    because in NetWare you can only see something when you have access to it (and
    the path to it), and by default users don't have access to SYS:ETC.  If your
    users do have full access to SYS:ETC, you may want to consider auditing your
    network, or hiring a professional (and trustworthy) security auditor who is
    familiar with NetWare and NDS to audit it for you.
    
    Randy Richardson - randy@inter-corporate.com
    Inter-Corporate Computer & Network Services, Inc.
    Vancouver, British Columbia, Canada
    http://www.inter-corporate.com/
    
    "Printing nightmares?  Enjoy sweet dreams with NDPS on NetWare."
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:19:26 PDT