Conference noted::hackers_v1

    Could it be that you are trying to fix the wrong problem?  The problem
    is not that the world has read access to the file, but that someone you
    don't want to give access to, might have access through world
    protection via the default DECnet account...  You might want to review
    your network objects.  If you have a micro-VAX, disable the default
    DECnet account, and only grant proxys.  If you have a macho-VAX, you
    migh have to implement different access criteria for different objects. 

    FJBlando
    
    P.S.  I agree, it is an enoying feature, but security is usually
    	  not easy.

>        Could it be that you are trying to fix the wrong problem?  The problem
>    is not that the world has read access to the file, but that someone you
>    don't want to give access to, might have access through world
>    protection via the default DECnet account...
    
    I don't think that's possible - NETWORK is a "right" and FAL accesses
    RIGHTSLIST (even with proxies...). 
    
    The DECNET account is just part of the problem. Try it yourself
    in the following scenarios and see if there is something I am missing
    here:
    
    1) Let SECURPAK set up auditing for your system. On every system
       I've ever seen it usually sets up auditing on file access failures.
    
    2) Now set the protection for RIGHTSLIST.DAT to "no world access".
    
    3) do ANYTHING via the network. FAL stuff is especially obnoxious.
       Now log in to an unprivileged account and type SHOW PROC/PRIV.
    
    4) Now set RIGHTSLIST.DAT back to world read but set an ACL to say
       (IDENTIFIER=NETWORK, ACCESS=NONE). This takes away the on-system
       failures, but you still get annoying messages from MAIL, PHONE,
       FAL, etc. Proxies don't work right either.
    
    I suppose we could be real creative here (we only have about 80+
    VAXen at this site) and make long ACL lists on RIGHTSLIST.DAT but
    then performance is degraded (isn't it?) for the smaller systems,
    and the larger systems like our manufacturing cluster which have
    LOTS of interaction over the network with other plants/systems then
    have yet more complicated access control setups.
    
    Is that what we need to do? RIGHTSLIST.DAT is one of those files
    that the system makes a LOT of use of (the reference monitor is
    based on it) and to restrict access to it removes a whole piece
    of security in itself. This is yet more confusing.....!
    
    /pjh
    
    
    

    	RIGHTSLIST.DAT should in general be world readable since many
    things need to access it. I do not regard user names on a system
    as particularly secure information. Apart from reading RIGHTSLIST.DAT
    they can be obtained from a SHOW USERS command, PHONE, or even ELF.
    
    	Of course, user names in SYSUAF.DAT do not have to be the same
    as the corresponding identifier names in RIGHTSLIST.DAT, but I would
    not go to the trouble of making them different. User names still
    have to be fairly public if you intend to allow incoming MAIL or
    PHONE connections, and your users will publicise their own if you
    allow NOTES on your systems.
    
    	If you have not already given the FAL object its own separate
    default object account, then it might be worth doing anyway. Then
    you could deny access to RIGHTSLIST.DAT to that account only. I
    do not think that would give too many troubles.

    		Dave

    
    re: .-1
    
    Thank you. No, our FAL object uses a different UIC (at least on
    production machines). I don't know that it's a good idea to deny
    access to RIGHTSLIST.DAT for anyone, it makes more noise to see
    "file access failure" messages ad nauseum than to just set alarm
    ACEs for the important ones. 
    
    /pjh

    Re: .3
    
    Sorry Dave, i must disagree.
    
    Why should RIGHTSLIST.DAT be world readable (apart from stopping
    security alarms). Programs such as MAIL are installed with SYSPRV
    so can read the file ANYWAY!                           
    
    Information in RIGHTSLIST is just as "secret" as SYSUAF, otherwise
    you could say "whats wrong with knowning what privs someone has",
    and why not take it further as make PAGEFILE.SYS world readable,
    after all, you can't actually CHANGE anything !!!!!
    
    VMS should (i thought it did) provide SYSTEM SERVICES to allow access
    to things like identifiers, which can then do the necessary checks
    before allowing access.
    
    Its just plain untidy to leave it unprotected
    
    mb

>        VMS should (i thought it did) provide SYSTEM SERVICES to allow access
>    to things like identifiers, which can then do the necessary checks
>    before allowing access.

 
    VMS does! Unfortunately if you don't have the privilege to use them
    (by virtue of the fact that your process doesn't have the privilege
    to open RIGHTSLIST.DAT) you then end up with no rights *and* the
    reference monitor logs your access failure too. (it does have the
    privilege).
    
    Like I said, just try $ SHOW PROC/PRIV.

    re .5:
    
    	"Information in RIGHTSLIST is just as "secret" as SYSUAF, otherwise you
    	could say "whats wrong with knowning what privs someone has", and why
    	not take it further as make PAGEFILE.SYS world readable, after all, you
    	can't actually CHANGE anything !!!!! "
    
    This is specious. Leaving sysuaf unprotected is a bit (but only a bit)
    unwise. It is rather like leaving a shopping bag on the seat of your
    car. You'd be better off putting it in the trunk, but as long as you
    leave the car locked, you'll probably be okay. Leaving the page file
    (or the dump file) unprotected is like leaving the keys in the
    ignition. No one has privacy if the page file is readable.
    
    On the other hand, if you make RIGHTSLIST unreadable, then you make it
    useless. Programs like DIRECTORY can't very well use it to translate
    UICs if they can't read it, now can they? If you're so paranoid that
    you're afraid someone might find out what identifiers there are, then
    maybe you really out to make do without a rightslist instead. Your
    system performance will be much better if DIRECTORY doesn't have to go
    through the error path of $OPEN every time someone looks at a file. 
    
    	Jon

    Reading this discussion, it sounds like some people may misunderstand
    what information is included in Rightslist.Dat.  Rightslist.Dat
    contains the ascii translations of UICs and other numeric identifiers.
    It does not contain a list of privileges or other information that
    can be used to determine what "rights" a user has.  That information
    is in Sysuaf.Dat.  Rightslist.Dat is a translation table between
    ascii and binary representations of the same information.
    
    For example, my UIC is [305,11] or something like that.  Rightslist.Dat
    contains the entries (translating the entries to something more
    readable):
    
    	[305,*]	 <---> 33F	(33F is my cost center)
    	[305,11] <---> GARDNER
    
    UICs are represented (in binary) as a 32 bit longword, with the group
    and member codes in separate 16 bit words.  A wild card (asterisk)
    is represented by all ones in the appropriate word.  Other rights
    identifiers are represented by 32 bit longwords with "magic" patterns
    in one or the other word.
    
    Programs that have access to a binary UIC use Rightslist.Dat to
    translate that into a more meaningful string.  For example, the
    file owner field in a directory listing.
    
    Any practical computer security system will use binary codes
    internally and ascii strings for human understanding.  The translation
    table between these is like a phone book --- while the ability to
    add new entries must be protected, there is no harm in publishing
    it for everyone to read.  If you are concerned that seeing a list
    of names will help someone make educated guesses, you have three
    choices:
    
    1.  Delete sensitive entries from the phone book (unlisted numbers)
    	or from Rightslist.Dat.
    
    2.  Use aliases in the phone book.  Or, make certain that the
	"usernames" that appear in Rightslist.Dat do not match the
    	real usernames in Sysuaf.Dat.
    
    3.	Include fake entries in the phone book, and detect any attempts
    	to use them.  For example, write a program that goes through
    	the ELF database or some other source of names, and makes
    	entries in Rightslist.Dat for all non-duplicates.  The vast
    	majority of names in Rightslist.Dat will not correspond to 
    	accounts on your system, so you will detect anyone using this
    	to try to guess account names.
    
    All of these make managing the system much more difficult.  But
    then, that seems to be the main purpose of security :-).

    re: .7
    
    	Read access to SYSUAF.DAT is dangerous because it allows me
    to do CPU speed testing of passwords without setting off security
    alarms.
    
    	On one system (managers and secretaries mainly) my programme
    found the passwords of 55 accounts in less than 20 seconds. During
    that time probably tens of thousands of passwords were attempted.
    Testing that number of passwords with login attempts would have
    been quite impractical - you cannot test at a rate of more than
    about one per minute without triggering breakin detection and alarms.
    
    	I can think of only one reason for protecting RIGHTSLIST.DAT
    against read access. If a user can read but not write to an object
    then he can see if there exists an identifier that would give him
    write access. Referring back through RIGHTSLIST.DAT will tell him
    whose account he has to break to get that identifier. Note that
    he must already have read access to the object since otherwise he
    cannot read the access control list of the object.
    
    	In general, if you have read access to an object you can make
    a pretty good guess as to who is allowed to write to it, so I do
    not regard this as too serious. Note that a change here would mean
    that the $FIND_HOLDER system service would have to require privileges
    of some sort too.

    
    re: .8, .9
    
    I understand what's in RIGHTSLIST.DAT too - remember this is a hackers
    notesfile, and hackers learn to use whatever information is available
    to their advantage.
    
    .9 gives the first realistic example of potential misuse of information
    stored in RIGHTSLIST.DAT - looking for identifiers which may allow
    access - I realize that no password, proxy or general account
    information is available in RIGHTSLIST.DAT - except for the UIC
    which the DUMP utility gladly gives me. What a UIC tells me is who
    has a system account (as long as the system UIC max hasn't been
    altered). Besides also giving me a list of potential account names
    to hack - they ARE 1/2 of the username/password combination.
    
    I understand far more about how RIGHTSLIST gets used and by what
    entities in VMS since .0. Dumping files over the network is still
    something I consider questionable not because I am paranoid about
    security (I'm not), but because it seemed like an anomaly in regards
    to recent corporate noise about said (or unsaid) security problems. 
    
    /pjh

    
    re .9
    
    	how about posting the program that got the passwords ?

    Re: < Note 455.11 by BIGALO::MACKAY_RANDY >
>    	how about posting the program that got the passwords ?
    Please, not here... 
    I wouldn't like to have to explain how this got out all over the
    place. Besides, this is the HACKERS conference, not the CRACKERS
    conference.
    	-Rick

    	I will not post the source code.
    
    	I hope the executable can be put in a later version of Securpack.
    This only lists the usernames that had weak passwords, and the code
    is deliberately rather obscure in the hope that it is no easier
    for a hacker to find out how it is checking passwords than it would
    be for him to find out how LOGINOUT checks them. He still needs
    read access to SYSUAF.DAT anyway.
    
    	The executable is currently being "field tested" by a few system
    managers round Europe.