Admin: link repair

2017-07-25T23:06:19Z

link repair

← Older revision		Revision as of 23:06, 25 July 2017
Line 36:		Line 36:
	<i>without</i> the confusion of multiple password tables. </li>		<i>without</i> the confusion of multiple password tables. </li>

	<li>Enhancements to the <var class="product">Model 204</var> <var>[[SECURE ~~FILE~~ command\|SECURE]]</var> command		<li>Enhancements to the <var class="product">Model 204</var> <var>[[SECURE command: File\|SECURE]]</var> command
	make it easier to manage security in complex, multiple online environments,		make it easier to manage security in complex, multiple online environments,
	while also eliminating certain security exposures. </li>		while also eliminating certain security exposures. </li>

JAL: link repair

2017-04-07T21:38:50Z

link repair

← Older revision		Revision as of 21:38, 7 April 2017
Line 61:		Line 61:
	The "file group" feature of <var class="product">Model 204</var> adds an additional two		The "file group" feature of <var class="product">Model 204</var> adds an additional two
	capability bits for each database file that is accessed as a group member.		capability bits for each database file that is accessed as a group member.
	All of these controls are documented in [[~~Security~~]].		All of these controls are documented in [[Model 204 security features]].

	===Subsystem access rights===		===Subsystem access rights===

JAL: /* SirSafe topics */ link repair

2017-03-03T21:56:55Z

SirSafe topics: link repair

← Older revision		Revision as of 21:56, 3 March 2017
Line 296:		Line 296:
	the [[M204wiki main page#rktools_notes\|RKTools release notes]].		the [[M204wiki main page#rktools_notes\|RKTools release notes]].

	For information about product error messages, see [[~~:Category:Sirius Mods~~ messages\|~~Sirius Mods~~ messages]].		For information about product error messages, see [[List of Model 204 messages#msir\|MSIR. messages]].

	{{Template: SirSafe topic list}}		{{Template: SirSafe topic list}}

	[[Category:SirSafe]]		[[Category:SirSafe]]

Admin: 1 revision: SirSafe pages

2016-11-30T21:32:40Z

1 revision: SirSafe pages

← Older revision	Revision as of 21:32, 30 November 2016
(No difference)

JAL: link repair

2016-11-30T21:06:30Z

link repair

New page

<var class="product">SirSafe</var> integrates the file security and access control mechanisms employed
by <var class="product">Model 204</var> with the native facilities of MVS (OS/390 and z/OS).
<var class="product">SirSafe</var> addresses several potential security exposures, while providing significant improvements in usability for large scale environments.
<var class="product">SirSafe</var> allows <var class="product">Model 204</var> to continue to use its proprietary security
mechanisms to manage access to the information contained in database
files, preserving its rich set of security controls.
In addition to improving security, the tight integration of <var class="product">SirSafe</var> with
modern MVS facilities enables support of read-only files, and it
simplifies file sharing among members of a sysplex.

==Overview==
<var class="product">SirSafe</var> functions as a layer on top of <var class="product">Model 204</var>, using the System Authorization
Facility (SAF) to control access to individual <var class="product">Model 204</var> file and group passwords.
SAF provides a standardized interface for accessing the services of a system
security manager such as RACF, ACF2, or Top Secret.
The <var class="product">Model 204</var> System Manager is still responsible for maintaining file and
group entries in a <var class="product">Model 204</var> password table (<code>CCASTAT</code>).
However, each user's access to particular file and group entries in the password
table is controlled by a system security manager, using rules entered by a system security officer.
Thus, even if a password is known to a user, that user may be prevented
from gaining the access rights conferred by the password.

<var class="product">SirSafe</var> can significantly improve the behavior of <var class="product">Model 204</var> in multi-system or sysplex environments.
In addition, <var class="product">SirSafe</var> extends the functionality of <var class="product">Model 204</var> database file security
in four important ways:
<ul>
<li>The security of data contained in <var class="product">Model 204</var> databases no longer depends upon
maintaining the secrecy of file and group passwords. </li>

<li><var class="product">SirSafe</var> can be configured to support read-only access to database files,
preventing unintended updates while reducing the number of users requiring
update access to <var class="product">Model 204</var> file data sets. </li>

<li>A given file or group password can confer different privileges,
depending upon the identity of the current user and the current Online,
without the confusion of multiple password tables. </li>

<li>Enhancements to the <var class="product">Model 204</var> <var>[[SECURE FILE command|SECURE]]</var> command
make it easier to manage security in complex, multiple online environments,
while also eliminating certain security exposures. </li>
</ul>

By providing control over who can use <var class="product">Model 204</var> file and group passwords,
<var class="product">SirSafe</var> allows the passwords to be freely shared, without the need for periodic changes.
Straightforward file and group passwords that are easy to remember, such as
<code>read</code>, <code>update</code>, or <code>sysprog</code>, can be freely
distributed and embedded in batch job streams.
Security is not compromised, because <var class="product">SirSafe</var> will verify access to the passwords for each user and for the submittor of batch jobs.

This is especially useful for large programming teams, where members may come and go.
Without <var class="product">SirSafe</var>, an ever-expanding circle of programmers become aware of key <var class="product">Model 204</var> file and group passwords, or the passwords need
to be changed frequently and redistributed to those users still authorized.
With <var class="product">SirSafe</var>, the system security administrator would simply change
the access rules for the affected user in order to grant or revoke
access to the required <var class="product">Model 204</var> file and group passwords.

==Model 204 database security==
<var class="product">Model 204</var> enforces a sophisticated array of controls to enforce security and integrity policies for its database files.
The access to each individual file is determined by fourteen independent capability bits, four
separate access levels for field-level security, and a procedure class designation.
The "file group" feature of <var class="product">Model 204</var> adds an additional two
capability bits for each database file that is accessed as a group member.
All of these controls are documented in [[Security]].

===Subsystem access rights===
Most end users access applications that are formally defined to <var class="product">Model 204</var> as application subsystems,
using the <code>SUBSYSMGMT</code> administrative tool described in
[[System requirements for Application Subsystems#Overview of the SUBSYSMGMT interface|Overview of the SUBSYSMGMT interface]].
Application subsystems are invoked from the <var class="product">Model 204</var> command level with a simple command, and then
the so-called "APSY" runtime uses information saved in the [[System requirements for Application Subsystems#Overview of CCASYS|CCASYS]] file to determine the
set of files and groups that need to be opened for the application along with
their appropriate access rights.
Users of application subsystems are not prompted for file or group passwords:
the subsystem definition identifies
the access granted for each user, with some users getting potentially different
privileges based upon their user ID.

<var class="product">SirSafe</var> does not affect how APSY assigns file or group privileges. SirSafe does, however, offer the use of Model 204 [[SirSafe command and function reference#Subsystem control commands|subsystem maintenance commands]] that simplify the stopping, starting, testing, and debugging of subsystems.

===Model 204 password table===
Programmers and DataBase Administrators frequently use the
<var class="product">Model 204</var> <var>OPEN</var>
command to access files and groups while they are developing applications and maintaining files.
The file or group access privileges granted as a result of an <var>OPEN</var> command depend upon the type of the file and upon the user-provided password, as follows:

<table class="thJustBold">
<tr><th>Public</th>
<td>The end-user is not prompted for a password, and the privileges are those that were specified as the default when the file or group was created.</td></tr>

<tr><th>Semipublic</th>
<td>The end-user is prompted for a password. The <var class="product">Model 204</var> password table is searched for a corresponding password (for the file or group being opened),
and if a match is found, the user is given the privileges from the matching entry. If a matching password is not found, the user is given the default privileges for the file, as specified when the file or group was created.</td></tr>

<tr><th>Private</th>
<td>The end-user is prompted for a password. The <var class="product">Model 204</var> password table is searched for a corresponding password (for the file or group being opened),
and if a match is found, the user is given the privileges from the matching entry. Otherwise the <var>OPEN</var> is rejected.</td></tr>
</table>
The <var class="product">Model 204</var> password table provides the ability to store multiple passwords for each
file or group.
A distinct set of access rights is associated with each password, so in effect the passwords become substitutes for named roles.
It is the development and the file maintenance roles that present the
greatest challenges, since they confer the strongest (update) privileges,
and they are frequently embedded in maintenance job streams.

==Model 204 password table (CCASTAT)==
The <var class="product">Model 204</var> password table (maintained in the sequential file <code>CCASTAT</code>)
is divided into three physical sections.
The <code>user ID</code> section contains one entry for each
ten-character login ID that is directly managed by <var class="product">Model 204</var>
(as opposed to the IDs managed by a "security manager" like RACF or ACF2).
Each user ID entry holds a one-way encrypted password and a set of login privileges.
Most users of <var class="product">SirSafe</var> do not use CCASTAT to manage login security; instead they typically use a formal security manager like RACF or ACF2.
For more information, refer to the Model 204 [[Security interfaces overview|security interfaces wiki pages]].

The <code>file</code> and <code>group</code> sections of CCASTAT contain the various one-way
encrypted passwords and the privileges they confer for <var class="product">Model 204</var> database files and groups.
The two sections are physically distinct so that a file and group of the
same name can have separately managed passwords.
A particular file or group may have multiple entries in CCASTAT, each
conferring a set of (possibly different) access rights and privileges.

The <var>[[LOGCTL command: Modifying user ID entries in the password table|LOGCTL]]</var> command is used to
maintain entries in the <var class="product">Model 204</var> password table.
Variants of the <var>LOGCTL</var> command are used to <var>A</var>dd, <var>D</var>elete or <var>C</var>hange entries in CCASTAT.
The basic form of the command is:
LOGCTL {A | D | C} key

The first argument indicates the type of operation being performed.
<var class="term">key</var> indicates both the type of entry as well as the specific entry:
<ul>
<li>For a file entry, <var class="term">key</var> must begin with a colon (<tt>:</tt>),
immediately followed by a one- to eight-character file or group name, then
one or more optional blanks and a single index character.
If no index character is present, a blank is assumed.</li>

<li>For group entries, the format is the same as for a file entry,
except the colon character is replaced by a comma (<tt>,</tt>).</li>

<li>For a login entry, a key contains from one to ten alphanumeric characters.</li>
</ul>

The following example deletes the password table entry for group <code>GARY</code> with an
index character of <code>C</code>, and then it adds an entry for file <code>ALEX</code> with index character <code>2</code>:
LOGCTL D ,GARY C
LOGCTL A :ALEX 2

After the second command completes, the end user is prompted to enter a password, privileges, and other access information, and a terminal mask, if any.

The three sections of the password table are maintained in the order of their
ten-byte key strings.
Thus all of the entries for a particular file follow each other, sorted in the
order of their index character (with blank coming first, of course).
The <var>LOGFILE</var> command is used to display the file entries in a CCASTAT,
producing output like:
<nowiki>:ALANPROC X'0201' 0, 0, 0, 0, 0, ALL
:ALANPROC A X'BFFF' 0, 0, 0, 0, 0, ALL
:ALANPROC 1 X'0CCC' 0, 0, 0, 0, 0, ALL
:ASDF X'BFFF' 0, 0, 0, 0, 0, ALL
:BACKUP X'8761' 0, 0, 0, 0, 0, ALL
</nowiki>
When a Semipublic or Private file or group is OPENed, the end user is
prompted for a password, which is immediately one-way encrypted.
Then the file or group section of CCASTAT is searched for a match on the
"middle" eight characters of the key.
For each file or group name match, the one-way encrypted password in the
entry is compared to the one-way encrypted value of the password provided by the end-user.
If they match, the privileges contained in the entry are granted to the <var>OPEN</var> request.
Otherwise, the scan continues until all entries for the file/group have been checked.

You can see that if two or more CCASTAT entries for a file or group contain the same password, the one with the lowest index character value will be the only one ever used.
The possibility of duplicate passwords, coupled with the fact that
<var>LOGFILE</var> and <var>LOGGRP</var> don't display password values, can cause a great deal of confusion.

SirSafe offers <var>LOGCTL</var>, <var>LOGFILE</var>, and <var>LOGGRP</var> enhancements to make password table maintenance simpler. See [[SirSafe command and function reference#LOGCTL enhancements for visible file/group entries|LOGCTL enhancements for visible file/group entries]] and [[SirSafe command and function reference#LOGFILE and LOGGRP enhancements|LOGFILE and LOGGRP enhancements]].

==SECURE and DESECURE commands==
Each password table contains an encrypted eight-character key value.
The <var>[[LOGKEY command|LOGKEY]]</var> command changes the key value from its default.
The <var>SECURE</var> command copies the current CCASTAT key value into the current default file.
Once this has been done, that file can only be opened by a copy of <var class="product">Model 204</var> using a CCASTAT with the same key value.
This feature can be used to prevent a malicious user from counterfeiting a
password table and using it to
obtain inappropriate access to a private or semipublic <var class="product">Model 204</var> database file.
Once a file has been successfully opened, the <var>DESECURE</var> command can be used to clear the key value
from the current default file so that it can once again be opened by an Online with any CCASTAT.

==Physical OPEN of Model 204 files==
Under MVS, <var class="product">Model 204</var> does a physical (operating system) OPEN of its database files with the INOUT option, using the access profile of the current job.
Because INOUT implies WRITE access to the file, the job's profile must
allow WRITE access, or the <var>Open</var> will be rejected with an IEC150I message.

The INOUT option is used because a subsequent <var>OPEN</var> for the same file uses the already opened DCB, so the initial <var>OPEN</var> must allow for READ or WRITE access.
While this is not typically a problem for Online jobs, it means that users running batch jobs
require WRITE access to the data sets of the <var class="product">Model 204</var> database files,
even if the files are opened with access privileges that do not allow updating.
This can raise concerns with Sarbanes/Oxley reporting requirements.

==Shared DASD enqueueing==
A shared DASD configuration allows a particular DASD device to be accessed by more than one computer system or operating system instance.
Shared DASD has become far more common with the advent of Logical PARtition
(LPAR) support, fiber-optic (ESCON) channels with EMIF sharing between LPARs, and Sysplex clusters.

<var class="product">Model 204</var> utilizes a variety of mechanisms to serialize the access and update of database files
among the various users in an online instance and between various instances of <var class="product">Model 204</var>.
The primary mechanism serializing database file accesses between various instances of
<var class="product">Model 204</var> is the operating system ENQ and DEQ facility.

When a database file is opened, <var class="product">Model 204</var> enqueues upon a resource name comprising the
database file name, the volume serial for the first (or only) data set of
the file, and the data set name for the first data set:
filename.volser.fully_qualified_dataset_name

The strength of enqueue (share or exclusive) depends upon the access intent for the file.
In order to support deadlock-free reduction in access strength, <var class="product">Model 204</var> uses three
different "queue names": <code>IFAMQA</code>, <code>IFAMQB</code>,
and <code>IFAMQC</code>.

This mechanism works well for cataloged and uncataloged data sets
referenced only from one operating system instance.
However, it breaks down when two instances of <var class="product">Model 204</var> running on
separate systems access the same file via shared DASD.
By default, the two operating system instances will not
share information about the enqueues used by <var class="product">Model 204</var>.
Thus, two separate instances of <var class="product">Model 204</var>, each running on different systems, can
simultaneously hold exclusive enqueues for the same resource.

The shared DASD support in <var class="product">Model 204</var> is based upon the concept of a "Shared DASD Enqueue List."
This enqueue list is a structure contained in the first page of the first (or only) data set of each database file, the File Parameter List (FPL) page.
An entry is placed in a file's enqueue list for every <var class="product">Model 204</var> instance that opens the file.
The entry is deleted when the file is physically closed by the instance, and the entry is updated if the instance changes its access intent for the file.

The shared DASD enqueue list is used during the <var class="product">Model 204</var> database file open process
to identify conflicts with <var class="product">Model 204</var> instances running under other operating system instances.
Each entry in the enqueue list contains the following information:

<table>
<tr><td nowrap>System name</td>
<td>A four-character name that identifies the system that is hosting the <var class="product">Model 204</var> instance, identified as the first field in message M204.0061.
For instances running under MVS, this ID will be the SMF system ID, set by the parameter <code>SID</code> in a <code>SMFPRMxx parmlib</code> member.
For instances running under CMS, this ID will be <code>CMS</code>.</td></tr>

<tr><td>Access intent</td>
<td>This is <code>EXCL</code> when a file is opened for update; otherwise, it is <code>SHR</code>.</td></tr>

<tr><td>Job name</td>
<td>For most operating systems, this is the job name of the <var class="product">Model 204</var> instance.
For instances of <var class="product">Model 204</var> running under CMS, it is the ID of the <var class="product">Model 204</var> virtual machine.</td></tr>

<tr><td>Step name</td>
<td>For most operating systems, this is the step name of the <var class="product">Model 204</var> instance.
For instances of <var class="product">Model 204</var> running under CMS, it is the six-character CPU serial number padded on the right with two blanks.</td></tr>

<tr><td>Date/Time</td>
<td>The date and time when the entry was added or last updated.</td></tr>
</table>

The open logic also removes obsolete enqueue entries that were established,
but no longer needed, by <var class="product">Model 204</var> instances executing under the current operating system instance.
Obsolete entries can result from system crashes, x22 ABENDs, and other infrequent (but ordinary) events.
The following logic is used:
<ol>
<li>Standard operating system ENQ/DEQ logic is used to enqueue
upon the specific database file.
If the enqueue fails, the open is rejected with file is in use.

<li>A hardware <code>RESERVE</code> is placed upon the volume containing the FPL page.
This prevents other systems from accessing the device and potentially
changing the enqueue list.

<li>The FPL is read and the shared DASD enqueue list is scanned for a conflict with the
access being requested by the current open.
<ol type="a">
<li>If an entry is found that conflicts with our access, but the entry was
established by a <var class="product">Model 204</var>
instance under our system, delete the entry because it is obsolete.
We know the entry is obsolete because the standard ENQ/DEQ mechanism under our operating system gave us the requested access.

<li>If a conflicting entry was established under a different operating system instance,
reject the open with M204.0582 access prevented by and M204.0584 file is in use messages.

<li>If all entries are processed with no current conflict, then add an entry for our requested access, and write the FPL back out to disk.
</ol>

<li>Release the hardware <code>RESERVE</code> on the volume containing the FPL page.
</ol>
If an <var>Open</var> request is prevented by an obsolete entry from a different operating
system instance, the <var class="product">Model 204</var> <var>ENQCTL</var> command can be used to clear out the offending entry.
If <var>ENQCTL</var> is used to delete a non-obsolete entry, then an <code>M204.0585 list overlaid</code> message results when the file is closed on the system whose entry was deleted.

==SirSafe topics==
The <var class="product">SirSafe</var> documentation consists of the pages listed below.
This list is also available as a "See also" link from each of the pages.

For information about product changes and Model 204 feature
support per <var class="product">SirSafe</var> version, see
the [[M204wiki main page#rktools_notes|RKTools release notes]].

For information about product error messages, see [[:Category:Sirius Mods messages|Sirius Mods messages]].

{{Template: SirSafe topic list}}

[[Category:SirSafe]]

SirSafe - Revision history

Admin: link repair

JAL: link repair

JAL: /* SirSafe topics */ link repair

Admin: 1 revision: SirSafe pages

JAL: link repair