Nope.
Unconfigured Ad Widget
Collapse
Announcement
Collapse
No announcement yet.
Why does IBM recommend QSECURITY = 50?
Collapse
X
-
Why does IBM recommend QSECURITY = 50?
Chances are you will not have any security or production problems. Depending on how your applications are written you could experience anywhere from a 2% to a 15% performance penalty (your mileage may vary ) according to IBM sources. So go to 50. Measure your performance. If it were 2-5% I would definetly do it. If it were more, well.... you'll have to make that call. jet
Comment
-
Why does IBM recommend QSECURITY = 50?
Interestingly my last 2 clients have considered themselves to be extremely security conscious but both have had QSECURITY set to 30. Unfortunately I've been there strictly as an application consultant and not in my preferred role as a systems administrator. My view is that 40 is the minimum acceptable level for a production system. Dave...
Comment
-
Why does IBM recommend QSECURITY = 50?
David, I'm not so sure. On a production system with commercially valuable data the cost of level 40 is so low for the extra protection I can't see how it's not justified. In the early days of level 40 some packages had problems with it. This was mainly because those packages were performing the sort of low level calls that level 40 was brought in to prevent. After all this time any software that still cannot run comfortably under level 40 has serious problems. Dave...
Comment
-
Why does IBM recommend QSECURITY = 50?
David, At QSECURITY 30, if you have authority to a *JOBD you can submit jobs to run with that *JOBD even if you're not authorized to the specific user profile in the *JOBD. But at QSECURITY 40, you need to be authorized to both the *JOBD and the specific user profile in the *JOBD. IMO, this alone is reason to go to QSECURITY 40. Regards, Chris
Comment
-
Why does IBM recommend QSECURITY = 50?
David, In addition to the JOBD loophole mentioned by Chris there's also a situation where a JOBD can be specified in the work station entries of a subsystem description potentially allowing users to access the system without signing on. The other major benefit of level 40 is the so called anti-hacking protection. Basically it prevents programs running in a user state from accessing privileged functions in the system domain. The main exposures here are from savvy programmers who might install their own routines, possibly disguised as a standard IBM utility, and from commercial software written, albeit innocently, to take advantage of internal system functions that IBM didn't make openly available. The presence of these routines threatens the integrity of your whole system. At one time the authors of commercial packages sometimes felt frustrated at the facilities offered in OS/400 and felt it necessary to exploit these low level calls to give their software extra functionality without sacrificing speed and efficiency. Nowadays, however, the huge range of APIs that IBM made legitimately available is supposed to have made these tricks unnecessary. Dave...
Comment
-
Why does IBM recommend QSECURITY = 50?
David, It sounds as if you are recommending security through obscurity. It only takes one end user (hacker) to buy an AS/400 security book and read it to potentially cause problems. And if these users connect with Client Access and you don't have the proper exit programs in place, they can launch OS/400 commands with RMTCMD even with LMTCPB(*YES). Chris
Comment
-
Why does IBM recommend QSECURITY = 50?
None of the users in these shops use RMTCMD. They can't even spell it, and do not know that it exists. There are only a few users who even know that they are on an AS/400. Most of the users simply know that they are on a "computer". If you ask them which computer, they will tell you "The one at my desk". As for the few who know, they are far too busy doing their jobs. They are simply not interested in the ins and outs of any aspect of operations. Dave
Comment
-
Why does IBM recommend QSECURITY = 50?
>This would not appear to be a problem in shops where the end users do not have command line access, the manager does not know what a job description is, and there is only one programmer.<<
I think that the operative word in this sentance is "appear". Initial appearance is that you've got everything locked up. Even a cursory second look may show that it is a problem because users do a have a command line (several actually), the manager doesn't need to know what a job description is, and there are in fact thousands of programmers (it's just that there is only one on the payroll who is authorized by management to access). But of course, if there are no PC's connected to your AS/400, there are no remote communications (LAN, ECS, etc.) to any other entity, and all your users are connected with just twin-ax attached dumb terminals, then I'm probably wrong jte
Comment
Comment