× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Phil, 

Would you care for a little open and spirited debate?

From an academic perspective, your arguments about LMTCPB seem sound,
but from a practical perspective, I don't think you could ever get
yourself to a place where Object Level Security was so tight that you
could leave all your users at LMTCPB(*NO).

The most obvious (to me) examples would be where you have an object
level security plan that gives a user *USE access to the Customer file,
and *CHANGE access to the Inventory File.   If this user is LMTCPB(*NO),
they can use the EDTF command to modify the contents of the Inventory
file in ways that are inconsistent with (and may break) the application.
The user could also use the OS/400 FTP command to send the Customer file
to a PC or another server and thereby compromise the entire data set in
one fell swoop.

The problem with straight object level security is that users are often
allowed to access data only with in a specific context - that is - it's
ok for Jane to access the Inventory file within the context on a well
crafted application program that controls what she can see and change.
But we don't want Jane to change some fields in the file (like re-order
point, etc.).  So *CHANGE authority would not in itself be adequate to
secure the resource.  

These are just two quick examples, and I am sure there are a lot more.
LMTCPB(*YES) gives system administrators a valuable tool that is easy to
implement and very effective at providing Context sensitive security.  I
don't believe it is antiquated, and I doubt it will every be obsolete.

But that is just MHO.

jte





--
John Earl | Chief Technology Officer
The PowerTech Group
19426 68th Ave. S
Seattle, WA 98032
(253) 872-7788 ext. 302
john.earl@xxxxxxxxxxxxx
www.powertech.com 
Celebrating our 10th Anniversary Year!
 

 
This email message and any attachments are intended only for the use of
the intended recipients and may contain information that is privileged
and confidential. If you are not the intended recipient, any
dissemination, distribution, or copying is strictly prohibited. If you
received this email message in error, please immediately notify the
sender by replying to this email message, or by telephone, and delete
the message from your email system.
--

-----Original Message-----
From: security400-bounces@xxxxxxxxxxxx
[mailto:security400-bounces@xxxxxxxxxxxx] On Behalf Of
Phil Ashe
Sent: Wednesday, September 06, 2006 2:22 PM
To: Security Administration on the AS400 / iSeries
Subject: Re: [Security400] Commands for Limited Users

I wanted to clarify some things about limit capabilities
and command
security.

Limit capabilities is part of the legacy support for
systems at security
level 10 or 20. It is a tool to solve a problem you
probably don't have.
It is designed to enforce a menu security system on
terminals when you
have no other security.

At security level 20 (security level 10 hasn't been
supported for
years), you aren't interested in managing object-level
security and you
have a very small set of tools to control user actions. In
this
environment, every user has *ALLOBJ rights and has the
ability to run
every command. There is no "security" except that which is
provided by
limit capabilities and menus. Limit capabilities and menus
provide the
means of controlling what users can do in an ad hoc
fashion.

At security level 20, you don't have object-level
security. As John Earl
pointed out, limit capabilities won't secure commands from
non-command
line interfaces, including commands from remote servers
and within
programs. It wasn't meant to. Limit capabilities was
designed for menu
security and not object-level security. This behavior
outside of menus
is to be expected.

Neither FTP nor Rexec is a classic OS/400 command line
interface managed
by limit capabilities functionality. Many of these types
of interfaces
didn't exist when the limit capabilities support was
created. If you
want to control access to commands in all interfaces
(programs
included), you need an object-level security scheme.

At security level 30 or higher, you have other options for
controlling
the actions of users, including object-level security. You
can simulate
the functionality of limit capabilities by a combination
of command
proxies, programs, specialized signon screens, and object-
level
security.

The benefit for managing limited capabilities is very
small at security
level 30 or higher, especially since you can provide for
similar
functionality through other means. For a similar amount of
effort, you
can turn on action auditing for users and determine actual
commands
being run. After an analysis of that data, you then hone
your object
security plan. Well-managed object security provides a
much bigger
benefit than limited capabilities.

CHGPWD shows some of the problems with limited
capabilities. The CHGPWD
command has no parameters. It's a command that almost
everybody should
have access to, but it is shipped with "Allow limited
user" set to
"*NO".

Why is it OK for a capabilities-limited user to access
CHGPWD by typing
"8" on the User Tasks menu (GO USER) but not type out
"CHGPWD" on a
command line on the same menu? It makes no sense.

Limit capabilities doesn't provide real security. It
doesn't provide
consistent security. Any auditor who insists on using
limit capabilities
doesn't understand the issues. I could argue that its use
does not
constitute a "Best Practice" in iSeries security.

Phil Ashe
NetIQ (A division of Attachmate)
1233 West Loop South, Suite 1800 | Houston, TX 77027 USA
713.418.5279 phone
phil.ashe@xxxxxxxxxxxxxx
www.netiq.com

-----Original Message-----
From: security400-bounces@xxxxxxxxxxxx
[mailto:security400-bounces@xxxxxxxxxxxx] On Behalf Of
John Earl
Sent: Wednesday, August 30, 2006 1:28 AM
To: Security Administration on the AS400 / iSeries
Subject: Re: [Security400] Commands for Limited Users

Jim,

Sorry, I should have been more clear.  This is the list of
commands that
limited capabilities are allowed to run from an OS/400
command line.
But as I mentioned earlier, there are other interfaces
that limited
capability users can use to run these (and other)
commands.

LMTCPB users can are not restricted from running other
commands from
within a compiled program - assuming they have at least
*USE authority
to the command object.

jte



--
John Earl | Chief Technology Officer
The PowerTech Group
19426 68th Ave. S
Seattle, WA 98032
(253) 872-7788 ext. 302
john.earl@xxxxxxxxxxxxx
www.powertech.com
Celebrating our 10th Anniversary Year!



This email message and any attachments are intended only
for the use of
the intended recipients and may contain information that
is privileged
and confidential. If you are not the intended recipient,
any
dissemination, distribution, or copying is strictly
prohibited. If you
received this email message in error, please immediately
notify the
sender by replying to this email message, or by telephone,
and delete
the message from your email system.
--

-----Original Message-----
From: security400-bounces@xxxxxxxxxxxx
[mailto:security400-bounces@xxxxxxxxxxxx] On Behalf Of
Jim
Franz
Sent: Tuesday, August 29, 2006 3:57 PM
To: Security Administration on the AS400 / iSeries
Subject: Re: [Security400] Commands for Limited Users

John - is this list commands they can execute from a
command line, or the
total list of commands they can execute, even if the
command is within
a clp program (assuming normal auth to the pgm, not
adopted, and the program
executing under the authority of the user of the
program,
not the owner)?
It was my understanding that this list was a limitation
of
what a limited
user
can do on a command line.
Jim Franz

----- Original Message -----
From: "John Earl" <john.earl@xxxxxxxxxxxxx>
To: "Security Administration on the AS400 / iSeries"
<security400@xxxxxxxxxxxx>
Sent: Tuesday, August 29, 2006 4:59 PM
Subject: Re: [Security400] Commands for Limited Users


Dave,

I'm reciting this from memory, so it may not be an
exhaustive list, but
if I recall correctly there were somewhere around 8
commands shipped
with the operating system that are available to
limited
users.  Let's
see which ones I can remember, and then we'll see if
others can chime in
with any I may have missed.

DSPJOB
DSPJOBLOG
DSPMSG
SIGNOFF
SNDMSG
STRPCO
WRKENVVAR
WRKMSG

Of these, SIGNOFF is virtually essential, and the
three
"DSP" and the
SNDMSG command are relatively inconsequential risk
(assuming you are
doing appropriate tightening elsewhere, as you have
said).  STRPCO is
risky, and probably completely unnecessary, and,
absent
a specific
reason to leave them open, the WRKENVVAR and WRKMSG
could afford to be
restricted as well.

This list only includes commands that are allowed by
Limited Capability
users as shipped from the factory.  You may have more
OS
commands or
application commands that have been opened to Limited
Capability users
as well.  There is at least one commercial product
(uh,
why yes, that
would be a PowerTech product :) ) that will show you
this list quickly
in a single report (and help you ensure that the list
stays constant),
but I am not aware of any automated facility in the OS
that will track
this parameter for you.

HTH,

jte


--
John Earl | Chief Technology Officer
The PowerTech Group
19426 68th Ave. S
Seattle, WA 98032
(253) 872-7788 ext. 302
john.earl@xxxxxxxxxxxxx
www.powertech.com
Celebrating our 10th Anniversary Year!



This email message and any attachments are intended
only
for the use of
the intended recipients and may contain information
that
is privileged
and confidential. If you are not the intended
recipient,
any
dissemination, distribution, or copying is strictly
prohibited. If you
received this email message in error, please
immediately
notify the
sender by replying to this email message, or by
telephone, and delete
the message from your email system.
--

-----Original Message-----
From: security400-bounces@xxxxxxxxxxxx
[mailto:security400-bounces@xxxxxxxxxxxx] On Behalf
Of
Turnidge, Dave
Sent: Tuesday, August 29, 2006 11:19 AM
To: Security Administration on the AS400 / iSeries
Subject: [Security400] Commands for Limited Users

I am trying to get a handle on security on our
systems,
and have now
arrived at "Commands for Limited Users." I have an
Excel
spreadsheet
which has all the commands in this category on our
systems.

First, I would like to know what are the commands for
limited users that
come with the system as shipped from IBM. Second, do
you
agree with that
list? I.e., should there be ANY commands available to
limited users?

I await your reply.

Thank you,

Dave

_______________________________________________
This is the Security Administration on the AS400 /
iSeries
(Security400) mailing list
To post a message email: Security400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:

http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the
archives
at http://archive.midrange.com/security400.



_______________________________________________
This is the Security Administration on the AS400 /
iSeries (Security400)
mailing list
To post a message email: Security400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the
archives
at http://archive.midrange.com/security400.



_______________________________________________
This is the Security Administration on the AS400 /
iSeries
(Security400) mailing list
To post a message email: Security400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the
archives
at http://archive.midrange.com/security400.



_______________________________________________
This is the Security Administration on the AS400 / iSeries
(Security400)
mailing list
To post a message email: Security400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the
archives
at http://archive.midrange.com/security400.


_______________________________________________
This is the Security Administration on the AS400 / iSeries
(Security400) mailing list
To post a message email: Security400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the
archives
at http://archive.midrange.com/security400.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.