Actually, the issue is having/taking the time to write utility programs that will do what the users have been able to do pre-SOX. There were users that were able to *ENABLE profiles. No more. However, a program was written that does this, and it can be selected from a menu. All is well ... almost. Dave -----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
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.