[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:	OLD ALL-IN-1 (tm) Support Conference
Notice:	Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:	IOSG::PYE

Created:	Thu Jan 30 1992
Last Modified:	Tue Jan 23 1996
Last Successful Update:	Fri Jun 06 1997
Number of topics:	4343
Total number of notes:	18308

451.0. "SYS$SM_CHANGE_LOG and administrators PB" by EVTAI1::PROT () Thu Apr 09 1992 18:18

    Diamond BL122D:
    
    When the PROFIL/UAF audit is set on, SYS$SM_CHANGE_LOG = 1 or 2, if a
    VMS unprivileged user, (ALL-IN-1 administrator), creates an account he
    gets the following error when the UAF entry is added :
    
    "Error opening file OA$DATA:SM_CHANGE_LOG.DAT"
    "insufiscient privilege or file protection violation"
    
    The cause of this problem is that there is an ACL on this file, setting
    the rights READ and EXECUTE for OA$ADMIN. But not WRITE.
    
    If I reset the symbol and turn off the auditing, of course the problem
    disappear.
    
    But now,if this ACL is set to WRITE, an admin could modify
    manually some records in the file. Security problem ? 
    
    Nevertheless, today, the audit isn't compatible with OA$ADMIN usage.
    
    I have not checked on BL123.
    
    Louis

T.R	Title	User	Personal Name	Date	Lines
451.1	Please file a QAR	IOSG::TALLETT	Just one more fix, then we can ship...	`Thu Apr 09 1992 22:06`	9
	> I have not checked on BL123. I think you'll find it is the same. You should QAR this. Regards, Paul
451.2	No "GING" in LOG :) !!!!	GIDDAY::SETHI	Man from Downunder	`Thu Nov 26 1992 00:32`	19
	Hi, The documentation is incorrect in the ALL-IN-1 Managers Guide on page 16-2 and 16-3. How to Turn Account Auditing On say <GET SYS$SM_CHANGE_LOGGING=1 Should read <GET SYS$SM_CHANGE_LOG=1 There is no "GING" :-) in LOG. Sunil PS - A bit like the DNS$SHR.EXE execpt it should have been DNS$SHARE.EXE.
451.3	A problem in Auditing or documentation ?	GIDDAY::SETHI	Man from Downunder	`Fri Nov 27 1992 00:06`	19
	Hi, Having read the documentation ( :0) for a change), page 16-1 Management Guide the customer has informed me that not all the details are logged. For example Edit an ALL-IN-1 account, including unlocking an account and moving an account to another disk As stated in the manual to me would mean doing an SM MUA SEL E, this transaction is not logged. However the unlock is I have not tested anything else. Does this need to be SPR'd ? And are there any other problems ? Thanks, Sunil
451.4	we should really log this in base	IOSG::TYLDESLEY		`Fri Nov 27 1992 11:08`	119
	Hello Sunil, You/your customer is indeed correct that simple edits to the Profile details are not logged (I have just changed the Delete_from field on an account, and it did not result in a security logging). I think, though, that I should add a little background to the design of this facility. When we incorporated it in Diamond, we intended it to be used as a basis for customization. The needs of individual customers in the security area are very different, so we did not try to best-guess them. We provided a simple mechanism, a data-file, and a simple means of viewing and accessing it. From there, it is really up to the customer to decide what else they want to do with it. Having said that, I do believe that one of the more important SM changes to log is that of a Profile edit via SM/SA$PROFILE. We do not do this, so this could be seen as an omission. Below I have included for your information a section the design spec for the SM change logging, and I think you will see that although we intended to include Edit in the logging, it was specific edits such as a Nominate, or where a WRITE ADD PROFIL was done that were picked up. I also agree with you that the documentation could be a bit clearer on this point. What follows is a piece from the outline spec, and does not necessarily reflect what was eventually built. I do not know whether we will have time/ effort, ever, to change the MUA E situation, but I think it is a good suggestion. I have arrowed >>> the parts I think are relevant. Cheers, DaveT =========================================================================== Extract from design spec of SM change logging: ---------------------------------------------- "Security-conscious customers require "change-logging" in SM/SA so that they may write customizations which analyze this logging - for example, by using VAX DATATRIEVE. Alterations to the entities "ALL-IN-1 account" and "VMS account" will be logged - majoring on the MUA (Maintain User Accounts) code (eg. Create Account, Edit Account, Delete Account, Change Password, Nominate Administrator, etc.). "Alterations" will be categorized as one of the following: . Add >>> . Edit . Delete . Copy (ALL-IN-1 account only) . Rename (VMS account only) The following more specific type of alterations will also be generated for Change Password and Nominate Administrator/Revoke Administrator, respectively: . Password . Nominate (ALL-IN-1 account only) Logging will be OFF by default - if the customer turns it on, it is their responsibility to interface to it, to maintain it, remember to turn it off, etc... It will be controlled by the setting of a SYS$ permanent ALL-IN-1 symbol - see first column of following table. The remaining 3 columns of the table relate to the actions of the logging script (see later) when called within the code. ------------------------------------------------------------------------------- SYS$SM_CHANGE_LOGGING Script tries Script logged Script's setting to log? successfully? status return --------------------- ------------ ------------- ------------- 0 or '' or undefined No - 1 (success) or invalid... 1 Yes Yes or No 1 (success) 2 Yes Yes 1 (success) Yes No 0 (failure) ------------------------------------------------------------------------------- >>> In subsequent ICOs, a call to the logging script will be made after every >>> SM/SA MUA instance of WRITE ADD\|CHANGE\|COPY\|DELETE PROFIL\|UAI$ >>> and after every AUTHORIZE command. ... The "PASSWORD" and "NOMINATE" action logging is at a higher, more general level than the other actions - these will be added in at appropriate places in the relevant code. Example of calling logging script from within code... GET #sm_actioner = 'ADMANAGER' GET #sm_actioned_type = 'A' GET #sm_actioned = 'CAUGHT_IN_THE_ACT' GET #sm_new_actioned = 'CAUGHT_IN_THE_ACT2' GET #sm_action = 'RENAME' GET #sm_a1_cmd = 'RNA' DO OA$LIB:SM_CHANGE_LOGGER .IF #sm_change_logger_status NES '1' THEN .GOTO generate_change_logging_error Note that for the actions "COPY" and "RENAME", the script generates a double (two-line) log entry - "COPY_FROM" & "COPY_TO" or "RENAME_FROM" & "RENAME_TO"... A new underlying entry form dataset SM$CHANGE$LOG keyed off a date/ time-stamp will map onto the log (132-column UI display possible since record length is 124 characters)... ... This entry form will map to the new data file OA$DATA_SHARE:SM_CHANGE_LOG.DAT which is to have (S:RWED,O:RWED,G,W) access and be provided in an Installation if it doesn't already exist. Note that as a further security measure, the SM$CHANGE$LOG entry form is a /MODE=INQUIRE one. It gets WRITE ADDed to by the logging script.
451.5	Customer may SPR the audit for editing	GIDDAY::SETHI	Man from Downunder	`Tue Dec 08 1992 02:29`	13
	Hi Dave, I have suggested to the customer that they customise the Audit as required. They are willing to do this BUT are unhappy that edit was not provided as a standard feature for auditing. I have also suggested if they are unhappy at not having editing profile as a auditable feature they should SPR it. The customer may do this so watch out :-) !!! Thanks for the background information it was most helpful. Sunil