Re: System value - Share Memory Control (QSHRMEMCTL)

I think I'd go the opposite direction...pushing back to the auditors to see
why they think this setting is a "good thing"

As Dan points outs, the system value really only affects Unix type and/or
Java apps. The entire IBM i OS is built around sharing. It doesn't make
sense to disallow it for one small class of apps.

The vulnerability mentioned, "APIs might potentially pose a risk to your
system and assets. A programmer can have write access and can add, change,
and delete entries in the shared memory or stream file." sounds scary.
Except I think it it leaves out the fact that with the i's object level
security, the programmer would still have to have the authority to change
to stream file in the first place.

Also, Carol Woodbury mentions, "For example, while the most secure setting
for the QSHRMEMCTL (shared memory) system value is ‘Off’, many features
won’t work – the APACHE admin instance won’t start, PASE applications
break, etc. Many of our clients use these considerations published in their
Risk Assessor documentation to justify to their auditors why they can’t set
certain system values to more stringent settings. "
http://www.readtech.com/pr/sv/OS400SecurityComplianceGuide.pdf

HTH,
Charles





On Tue, Jan 7, 2014 at 12:06 PM, Dan Kimmel <dkimmel@xxxxxxxxxxxxxxx> wrote:

You're not going to see the shared memory api's used very much in
applications that were written for IBMi. So I don't think there should be
any impact at all in preventing a user from writing to shared memory.

Shared memory is a tool for parallel programming in Unix. The api's in
question are POSIX standard so IBMi supports them. They really aren't
needed in IBMi programming as any IBMi job can share memory it has
allocated with any other job by passing the abstracted (Single Level
Storage) pointer. The architecture behind Unix has no abstracted pointers,
only absolute offsets within the program that the operating system combines
with a base pointer it keeps for each job to the real address of the
memory. A *nix program must ask the operating system to allocate a shared
memory segment and must do all work on that segment using an offset pointer
given it by the OS.

All this system value does is restrict the users who can WRITE in a shared
memory segment allocated in the above manner. It does not restrict which
users can create a memory segment or who can read a memory segment. The
user who creates the segment owns it and can always write to it. Most
parallel jobs using shared memory have a "server" who owns the segment and
"clients" who read what's there. That scenario would not be affected. There
are models where several users attach and write in the segment. These
operations must be protected by semaphores or some other method to prevent
concurrent writes on out-of-date segments. The OS provides the semaphores
for use by the programmer, but no inherent protection against concurrent
writes in a multiprocessor environment.

If it was me, I'd turn on the system value in a test partition and run
through my application test suite to see if anything breaks.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Steinmetz, Paul
Sent: Tuesday, January 07, 2014 10:13 AM
To: 'Midrange Systems Technical Discussion'
Subject: System value - Share Memory Control (QSHRMEMCTL)

Security audit is requesting we change this from 1 (share) to 0 (cannot

share).

Has anyone dealt with this, notice any performance hits when setting to

0.

The Share Memory Control (QSHRMEMCTL) system value defines which
users are allowed to use shared memory or mapped memory that has write
capability.
Your environment may contain applications, each running different jobs,

but

sharing pointers within these applications. Using these APIs provides for
better application performance and streamlines the application

development

by allowing shared memory and stream files among these different
applications and jobs. However, use of these APIs might potentially pose

a

risk to your system and assets. A programmer can have write access and

can

add, change, and delete entries in the shared memory or stream file.
To change this system value, users must have *ALLOBJ and *SECADM special
authorities. A change to this system value takes effect immediately.
Note: This system value is a restricted value. See Security system
values<

http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzarl/rzarlsy

sval.htm#rzarlsysval> for details on how to restrict changes to security
system values and a complete list of the restricted system values.
Table 1. Possible values for the QSHRMEMCTL system value:

0

Users cannot use shared memory, or use mapped memory that has write
capability.
This value means that users cannot use shared-memory APIs (for example,
shmat() - Shared Memory Attach API), and cannot use mapped memory
objects that have write capability (for example, mmap() - Memory Map a

File

API provides this function).
Use this value in environments with higher security requirements.

1

Users can use shared memory or mapped memory that has write capability.
This value means that users can use shared-memory APIs (for example,
shmat() - Shared Memory Attach API), and can use mapped memory objects
that have write capability (for example, mmap() - Memory Map a File API
provides this function).



Thank You
_____
Paul Steinmetz
IBM i Systems Administrator

Pencor Services, Inc.
462 Delaware Ave
Palmerton Pa 18071

610-826-9117 work
610-826-9188 fax
610-349-0913 cell
610-377-6012 home

psteinmetz@xxxxxxxxxx<mailto:psteinmetz@xxxxxxxxxx>
http://www.pencor.com/

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.