Re: Commands for Limited Users

I worked on level 20 machines way back when. It was a struggle to
configure the "security" such that people could do their work and not
mess up the results of others. I ended up writing a bunch of programs,
commands and OCL to get the flexibility we wanted on these machines. 

Let's take Rob's CLROUTQ command as an example. 

You don't want every user to clear any output queue. Maybe you want some
users to be able to clear some queues. Limit capabilities won't solve
that problem alone. It needs a helper program or command to provide some
level of security to the output queues. Back in the day, you created a
command MYCLROUTQ. You need a command in order for LMTCPB to work.

Without object security, if you enable the command MYCLROUTQ such that
LMTCPB(*YES) users can run it, then any user with a command line can
clear the output queues allowed by the command. Otherwise only users who
are LMTCPB(*NO) or LMTCPB(*PARTIAL) can run the command. LMTCPB(*NO) and
LMTCPB(*PARTIAL) users can *type* any command on a command line. 

If you want to enable some LMTCPB(*NO) users to run the MYCLROUTQ
command but not others, then the facilities provided by LMTCPB don't
help you. And it certainly doesn't help you on other interfaces like FTP
or rexec.  

If you aren't authorized to run a command, LMTCPB(*NO) won't grant you
that authority. If you are authorized to run a command, but are
LMTCPB(*YES), then you have a consistency problem, like I outlined
earlier with CHGPWD. 

The consistency problem is easy to resolve. You get a different message
for LMTCPB violations (CPD0175) than for object security violations
(CPD0032). However only the object security violation generates any type
of system audit journal activity. 

LMTCPB is checked after object security. If a user doesn't have object
authority to run a command and the command is also ALWLMTUSR(*NO), you
see the authority failure and not the LMTCPB violation. 

It seems to be a lot of work to manage LMTCPB for very little benefit.
If you don't want a user to run a command, then take away their
authority to the command. You will have stopped them everywhere. LMTCPB
leaves too many holes. It is checked in very few places (terminal
command lines or command entry screens), and after a user's authority to
a command has been validated. 

If your object security for commands is well designed, then users are
executing commands which you have previously approved. All LMTCPB(*YES)
is going to do is make the end users' jobs harder because there are
commands they can execute in some places but not others. If you are
relying on LMTCPB(*YES) to be a safety net and stop certain activity, I
think you will find some large holes to fall through. The information
you need for LMTCPB violations is in the user's joblog, which hopefully
is still around.

I would focus on tightening object security to the commands rather than
tightening LMTCPB. Not only will this reduce the hanky panky activity,
but you will get a useful audit trail of the shenanigans in the system
audit journal. You have better information for real policy violations.
If you rely on LMTCPB(*YES) to catch problems, the shenanigans are only
caught in the user's interactive joblog. 

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 rob@xxxxxxxxx
Sent: Thursday, September 07, 2006 8:13 AM
To: Security Administration on the AS400 / iSeries
Subject: Re: [Security400] Commands for Limited Users

I think I'll straddle the fence.  Phil is right.  I don't think it is
minutiae.  However, it does slow down many users from doing commands
they shouldn't.  And as much as a GUI, done right, can help
productivity, having a way to access stuff that's been common knowledge
for the last 15 years, like many of the commands, can be useful.
Whacking some of the usefulness out of it so that the users will have to
work harder to poke around in the wrong areas may be enough to reduce
their hanky panky. Note: 
 I did say reduce, not eliminate.
Like the analyst who no longer works here that taught the users CLROUTQ
QEZJOBLOG to reduce their spool files.
Or the application vendor who teaches end users how to mess with job
priorities and stuff.

It's up to you if "reduce" is good enough.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





"Turnidge, Dave" <DTurnidge@xxxxxxxxxxxxxxxxxxxx> 
Sent by: security400-bounces@xxxxxxxxxxxx
09/07/2006 08:21 AM
Please respond to
Security Administration on the AS400 / iSeries
<security400@xxxxxxxxxxxx>


To
"Security Administration on the AS400 / iSeries" 
<security400@xxxxxxxxxxxx>
cc

Subject
Re: [Security400] Commands for Limited Users






Well, "back in the day", it was a big deal to place a command line as
part of our menuing system, and in many cases as an option in many
programs. So, limit capabilities is quite important in our situation. 

I am sure there are many ways to track many different items to be able
to control things on a command by command basis, but then I would be
repeating another level of what we have been forced to do by the
government, and then the auditors already. However, when things start
slowing down, I'm sure we'll look at additional minutiae...

Dave 

-----Original Message-----
From: security400-bounces@xxxxxxxxxxxx
[mailto:security400-bounces@xxxxxxxxxxxx] On Behalf Of Phil Ashe
Sent: Wednesday, September 06, 2006 4: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 


_______________________________________________
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.