|
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 OfJimFranz 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 theprogram,not the owner)? It was my understanding that this list was a limitationofwhat 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 UsersDave, I'm reciting this from memory, so it may not be anexhaustive list, butif I recall correctly there were somewhere around 8commands shippedwith the operating system that are available tolimitedusers. Let'ssee which ones I can remember, and then we'll see ifothers can chime inwith any I may have missed. DSPJOB DSPJOBLOG DSPMSG SIGNOFF SNDMSG STRPCO WRKENVVAR WRKMSG Of these, SIGNOFF is virtually essential, and thethree"DSP" and theSNDMSG command are relatively inconsequential risk(assuming you aredoing appropriate tightening elsewhere, as you havesaid). STRPCO isrisky, and probably completely unnecessary, and,absenta specificreason to leave them open, the WRKENVVAR and WRKMSGcould afford to berestricted as well. This list only includes commands that are allowed byLimited Capabilityusers as shipped from the factory. You may have moreOScommands orapplication commands that have been opened to LimitedCapability usersas well. There is at least one commercial product(uh,why yes, thatwould be a PowerTech product :) ) that will show youthis list quicklyin a single report (and help you ensure that the liststays constant),but I am not aware of any automated facility in the OSthat will trackthis 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 intendedonlyfor the use ofthe intended recipients and may contain informationthatis privilegedand confidential. If you are not the intendedrecipient,anydissemination, distribution, or copying is strictlyprohibited. If youreceived this email message in error, pleaseimmediatelynotify thesender by replying to this email message, or bytelephone, and deletethe message from your email system. -------Original Message----- From: security400-bounces@xxxxxxxxxxxx [mailto:security400-bounces@xxxxxxxxxxxx] On BehalfOfTurnidge, 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 oursystems,and have now arrived at "Commands for Limited Users." I have anExcelspreadsheet 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, doyouagree 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/security400or 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/security400or email: Security400-request@xxxxxxxxxxxx Before posting, please take a moment to review thearchivesat 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 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.