ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

AUDITING: INLPGM, INLMNU and *LMTCP

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • AUDITING: INLPGM, INLMNU and *LMTCP

    Hi everyone,

    Thanks so much for all of your answers on the previous topic.
    Unfortunately I can't reply to the posts - i don't know why there's no reply button If you could tell me how, we could elaborate further and I could reply on your answers.

    1. I would have another question tho - i'd like to understand what the user is able to do and the differences between the following scenarios:
    - Initial Menu = OperationX, and Initial PGM = *NONE, and LMTCTP = YES
    - Initial Menu = SIGNOFF, Initial PGM = ABC, and LMTCTP = Yes

    2. what's bugging me most here is - if INLPGM is set and MENU is SIGNOFF, what is the program doing? Just loading the data and menu? Then if I have both a set menu and a set initial program, whats the difference? Is there a more risky scenario ?
    Last edited by kitvb1; May 5, 2017, 01:02 AM. Reason: merged posts

  • #2
    Hello guys !

    My name is Math!

    I am trying to learn more about critical security aspects of AS/400.
    I have important questions that I'd like to get your input on.

    I am still learning, 20 years old, and if I understand that your time is very valuable and although maybe short, I will benefit a lot from your answers.

    Thanks a million in advance!

    Please note that I ask those questions having already read pages and articles and hundreds of pages on AS/400 and IBM security...

    1. Let's say command XYZ has PUBLIC set to *EXCLUDE. If I have access to command line and not *ALLOBJ, I cannot access that command, right? If I have *ALLOBJ or belong to the authorization list, then I can launch it?

    2. Second question: if a user have full access to command line (Limit cap = *NO), but does not have *ALLOBJ or *SECADM, can that user still create profiles or change security? What can that user do with the command line that would be risky?

    3. Third question: a lot of people argue usually on this: if the user only has *SECADM and not *ALLOBJ, that user cannot create profiles or modify security. I don't agree, but I wanna make sure I obtain the right answer. User with *ALLOBJ and not *SECADM cannot CHGUSRPRF, but he could ultimately find the way to obtain *SECADM?

    4. Let's say you have 3 libraries which contain the source data and financial files and programs. You have a tool call Turnover to put changes in production. Only IBM can have level 40 + and put in production the changes. However, when I look at the authorities on those 3 libraries, I see PUBLIC set to *CHANGE and other groups. Does that mean anybody can access those libraries and change the data (source and financial)? Is the tool then useless? What's the nuance here in terms of authority at the library level vs. the changes Tool Turnover or Implementer.


    5. Say I have a financial system that is the G/L application resides on that AS/400 server. If I want to look at the authorities on the financial data, does that mean I have to look at the source libraries? Are those the same libraries as the financial data or the source is purely changing the application code only?



    6. If I have users with *ALLOBJ, but no access to command line, how does the user access those *any* objects on the server or app? Do you agree that that user could also manage to get a CL ? If I look at a client's screen and they say " yeah I have allobj but see? I dont have a CL and my menu shows only 2-3 options.. so how do you think I'd access all of the objects on the server eventhough I have *ALLOBJ? "



    THANKS SO MUCH IN ADVANCE !

    Comment


    • #3
      Start with a general principle: If you have *ALLOBJ, then you can obtain any other authority that you want. And with that always in mind, study the Authority checking flowcharts and learn to refer to them until you feel comfortable. The authority-checking scheme has a reasonable design, and it won't be long before many things become obvious.

      From there, consider whether or not there are any networking services active on the system. If there are any, consider how useful it is to be restricted to a menu with only two or three options when remote commands need no menu at all. And if a user claims not to know anything about remote commands, consider how many things are learned every day by "googling for them".

      Networking messes up a lot (the vast majority) of "menu-based" systems.

      If there somehow happens to be no networking services running, then access should be only through direct-attach terminals. If so, is the default logon panel for entry of user/password used, or is a custom version supplied that only allows 'User' and 'Password'? If it's not custom, do user profiles have the LMTCPB(*YES) attribute set? If not, then the assigned initial program or menu isn't guaranteed. Any startup menu or program may be chosen for the session as long as they're authorized for use. (And with *ALLOBJ, every object is authorized to the user.)

      Maybe that's enough to answer most of your questions. Later for a couple follow-ups.
      Tom

      There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

      Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

      Comment


      • #4
        As has been mentioned, the security manual and the authority checking flowchart (which looks quite daunting) will answer most of these questions.

        Originally posted by Math555 View Post
        1. Let's say command XYZ has PUBLIC set to *EXCLUDE. If I have access to command line and not *ALLOBJ, I cannot access that command, right? If I have *ALLOBJ or belong to the authorization list, then I can launch it?
        Not easy to answer as other factors will come into play. Considerations such as: who is the owner of the object, are there any private authorities on the object, is an authorisation list associated with the object, what group profiles does this user have. All these factors need to be taken into consideration. There's also the question of whether the object could be accessed via a program using adopted authority etc.

        Originally posted by Math555 View Post
        2. Second question: if a user have full access to command line (Limit cap = *NO), but does not have *ALLOBJ or *SECADM, can that user still create profiles or change security? What can that user do with the command line that would be risky?
        Again, hard to answer. If for instance a program has been created to do this and it adopts sufficient authority, then a person could create profiles. And as per your previous question, what about group profiles? Can they access these commands via them? Also note that limited capability doesn't guarantee someone can't run commands on the system. It's a very false "security" option. As an example, if a user gets access to a system menu then they can run any commands from that menu regardless of the limited capabilities setting. And note, as Tom mentioned above, the initial menu can be changed on the signon screen (unless the limit capabilities is set to *YES) unless a custom one is used that doesn't have the initial menu option or some custom program runs to enforce an application menu or something.

        Originally posted by Math555 View Post
        3. Third question: a lot of people argue usually on this: if the user only has *SECADM and not *ALLOBJ, that user cannot create profiles or modify security. I don't agree, but I wanna make sure I obtain the right answer. User with *ALLOBJ and not *SECADM cannot CHGUSRPRF, but he could ultimately find the way to obtain *SECADM?
        To create profiles, you only need *SECADM authority. Note as per previous comments, that authority need not be in the profile but could be in a group profile or some other means. To change a profile, the person must have access to the profile in question. This doesn't necessarily require *ALLOBJ authority, it could come from a group profile or some other means (e.g. if they created a profile, they'd be the owner and therefore have full access to it). As to your second point, that someone with *ALLOBJ could ultimately find a way to obtain *SECADM, that is definitely true. E.g. submitting a job under another profile or via a very simple program. As such, giving a profile *ALLOBJ authority is giving them unrestricted access to your system.

        Originally posted by Math555 View Post
        4. Let's say you have 3 libraries which contain the source data and financial files and programs. You have a tool call Turnover to put changes in production. Only IBM can have level 40 + and put in production the changes. However, when I look at the authorities on those 3 libraries, I see PUBLIC set to *CHANGE and other groups. Does that mean anybody can access those libraries and change the data (source and financial)? Is the tool then useless? What's the nuance here in terms of authority at the library level vs. the changes Tool Turnover or Implementer.
        I would suggest looking at the security manuals, the apendices contain information on authority needed by commands to perform operations on objects etc. A library is an object so the authorities on that are important but also the authority on the objects within the library. And as has been mentioned previously, authority can come from more than just the profile, there are group profiles, software adopting authority etc to take into consideration.

        Originally posted by Math555 View Post
        5. Say I have a financial system that is the G/L application resides on that AS/400 server. If I want to look at the authorities on the financial data, does that mean I have to look at the source libraries? Are those the same libraries as the financial data or the source is purely changing the application code only?
        Not sure what you mean by the source libraries. The libraries containing the DDS/program source code? That wouldn't be relevant. As previous comments though, authority can come from many sources.

        Originally posted by Math555 View Post
        6. If I have users with *ALLOBJ, but no access to command line, how does the user access those *any* objects on the server or app? Do you agree that that user could also manage to get a CL ? If I look at a client's screen and they say " yeah I have allobj but see? I dont have a CL and my menu shows only 2-3 options.. so how do you think I'd access all of the objects on the server eventhough I have *ALLOBJ? "
        I personally would never trust that. Some programs for instance allow you to bring up a command line (e.g. with F21 in SEU). There's also access to the system via other means (ODBC, JDBC, Navigator etc etc etc). There are far too many variables to make that even remotely safe. *ALLOBJ is a very powerful authority and with anyone savvy on the systems it's quite likely they'll get around "not having" a command line. A sound authority scheme on your system should restrict the requirement for *ALLOBJ to just a few people.

        Comment


        • #5
          Originally posted by Math555 View Post
          Please note that I ask those questions having already read pages and articles and hundreds of pages on AS/400 and IBM security...
          First, they're all good questions. They lead to scenarios that are one or more levels removed from what's on the surface when starting security research. To add to what's been said, I'll make a few more general comments because direct 'yes/no' answers are almost always misleading. So, in addition to all previous comments...

          1. Let's say command XYZ has PUBLIC set to *EXCLUDE. If I have access to command line and not *ALLOBJ, I cannot access that command, right? If I have *ALLOBJ or belong to the authorization list, then I can launch it?
          The ability to run a command from a "command line" is determined by a couple factors: "limited capability" and authority.

          "Limited capability" is determined by two attributes: First, the LMTCPB() attribute of a user profile determines whether a user may enter all authorized commands or only authorized commands that have the ALWLMTUSR(*YES) attribute. This doesn't determine if a user may "run" a command, but only if the user can run a command through an interface that enforces the LMTCPB() attribute. Most interfaces don't enforce it; it was intended for control of "command lines" and not for uses such as FTP scripts or SQL procedures, both of which have dedicated control features.

          Regardless of "limited capability", a user may not run any command without sufficient authority to the *CMD object as well as to any *PGM (or other) object that the *CMD object requires.

          That only partially answers the question, though, because authority isn't exactly controlled for a job's user. Rather it's better thought of as controlled for the "process" that the user is running. (Process -- the job, the currently running program or procedure, etc.) The authority for any attempted action may be gathered from many sources in a defined sequence. As soon as a specifically explicit authority is found, authority checking stops.

          Example:

          *DTAARA ABC has this authority:
          Code:
                                     Object  
          User         Group        Authority
          *PUBLIC                   *CHANGE  
          TOML                      *ALL     
          LOAUT0                    *EXCLUDE
          Profile LOAUT0 is a regular user but has profile HIAUT as its group profile, and HIAUT has *ALLOBJ. However, if LOAUT0 runs DSPDTAARA ABC, the result is CPF1016, "No authority to data area ABC in library." That's because of the defined sequence. Private authorities are checked before group authorities, and there is a LOAUT0 private authority found. Checking goes no farther.

          *DTAARA DEF has this authority:
          Code:
                                     Object  
          User         Group        Authority
          *PUBLIC                   *EXCLUDE 
          TOML                      *ALL
          If LOAUT0 runs DSPDTAARA DEF, it suceeds because group authority is checked before *PUBLIC authority. Although the group profile doesn't have a private authority, *ALLOBJ is still checked for the group before *PUBLIC. The *PUBLIC *EXCLUDE isn't reached in the authority checking sequence.

          The point is simply that authority can come from various sources (more are available to developers), but there is a predictable pattern you can use.

          2. Second question: if a user have full access to command line (Limit cap = *NO), but does not have *ALLOBJ or *SECADM, can that user still create profiles or change security? What can that user do with the command line that would be risky?
          Without *SECADM (however it may be obtained), a user cannot create, delete nor modify user profiles. But to "change security", other elements are considered. The name "*SECADM" is misleading in that respect. Its connection to 'security administration' is mostly limited to *USRPRF objects and activities involving the /QDLS file system. It doesn't otherwise allow 'changing security'. I.e., a user with *SECADM doesn't get the authority to change authorities for programs, files or other objects in most file systems (including /root and /QSYS.LIB).

          Also, never confuse USRCLS(*SECADM) with SPCAUT(*SECADM). They have only a very minimal connection. The USRCLS(*SECADM) only affects the default special authorities that are assigned when a *USRPRF object is created/changed and SPCAUT(*USRCLS) is specified. There may be various menus that show or hide some options for users with USRCLS(*SECADM), but that's not due to an authority check. It's simply from the 'user class'. A user might still be able to perform the action of a hidden menu option if the action is initiated outside of the menu, e.g., by directly calling the program behind the option. IOW, for most security-related questions, USRCLS() can be ignored,

          3. Third question: a lot of people argue usually on this: if the user only has *SECADM and not *ALLOBJ, that user cannot create profiles or modify security. I don't agree, but I wanna make sure I obtain the right answer. User with *ALLOBJ and not *SECADM cannot CHGUSRPRF, but he could ultimately find the way to obtain *SECADM?
          A *SECADM (special authority) user can create, change and delete any user profiles to which that user has sufficient authority. With *ALLOBJ, sufficient authority is guaranteed.

          There might be a Payroll manager who's been given *SECADM along with sufficient authority to a set of users who work in the Payroll department. Assuming that the manager also has been given authority to all Payroll-related objects, then that manager can create new Payroll-related user profiles as well as change or delete existing Payroll profiles. That manager can grant or revoke any authority for Payroll objects to any Payroll profile as long as the authority is one that the manager already has. If the manager has no authority to any G/L objects, then no G/L authorities can be conferred to anyone by that manager. The *SECADM is related to 'changing authority' of Payroll objects only as far as it causes any changes to *USRPRF objects. It doesn't relate to changes to Payroll objects themselves; that authority is derived from elsewhere.

          Note that granting a private authority to some user to access some object doesn't involve a change to the target *USRPRF object. Therefore, *SECADM is not involved. A "private authority" to, say, a *FILE object involves only the *FILE object. Therefore, even if the manager has no authority to some G/L user profile, the manager is still allowed to set a private authority on a Payroll *FILE that gives the G/L user (or any other user) the authority to access the *FILE. Private authorities are stored with the 'object' and not with the 'user'.

          4. Let's say you have 3 libraries which contain the source data and financial files and programs. You have a tool call Turnover to put changes in production. Only IBM can have level 40 + and put in production the changes. However, when I look at the authorities on those 3 libraries, I see PUBLIC set to *CHANGE and other groups. Does that mean anybody can access those libraries and change the data (source and financial)? Is the tool then useless? What's the nuance here in terms of authority at the library level vs. the changes Tool Turnover or Implementer.
          For most circumstances, *CHANGE to a library means that objects can be added to or removed from that library. A library effectively is a directory or index of objects within the library. It's a separate object from things that it contains. You might be able to change index entries, but only if you also have sufficient authority to the actual *PGM or *FILE or whatever object is involved. As a user, you might have *ALL authority to a *FILE object; but if you have *EXCLUDE authority to the *FILE's library, you can't get at the *FILE to do anything with it.

          Authority to a library can get you 'in the door'. It doesn't necessarily allow you even to see anything within the library.


          5. Say I have a financial system that is the G/L application resides on that AS/400 server. If I want to look at the authorities on the financial data, does that mean I have to look at the source libraries? Are those the same libraries as the financial data or the source is purely changing the application code only?
          Impossible for us to say without reviewing the system. Assuming that "source" always and only refers to "source code that is intended to be compiled", I personally would have separate 'source' and 'data' libraries. Quite likely I'd also have a separate 'program' library for executeables (compiled programs, etc.). Developers would not have authority to production 'data' libraries.

          6. If I have users with *ALLOBJ, but no access to command line, how does the user access those *any* objects on the server or app? Do you agree that that user could also manage to get a CL ? If I look at a client's screen and they say " yeah I have allobj but see? I dont have a CL and my menu shows only 2-3 options.. so how do you think I'd access all of the objects on the server eventhough I have *ALLOBJ? "
          If you're using, say, a Windows 7 desktop and the business runs off of a Windows Server setup, the access there is through network interfaces. Many of the same network protocols will allow a user with a Win7 desktop similar access to IBM i objects. ODBC/JDBC is pretty widely known. Or perhaps you're familiar with rexec. Or... many choices.

          That doesn't mean that any user will ever try anything. Still, few businesses trust every employee and consultant enough to leave doors and windows at the business site unlocked or open all night and over weekends and holidays. And if, say, the business has a safe or vault with valuables in it, employees aren't given the combinations by default.

          Perhaps the employee is indeed always and forever absolutely 100% trustworthy and reliable. How does that stop Joe Blackhat from hacking that user's account, logging on and creating total havoc by deleting the entire system -- all done in the name of the actual innocent user. But since all evidence points only to Ms. Innocent, how does she defend herself? The user perhaps should be the first one to demand that unnecessary capabilities are removed from her user profile.
          Tom

          There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

          Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

          Comment


          • #6
            Originally posted by tomliotta View Post
            Private authorities are stored with the 'object' and not with the 'user'.
            Have to disagree with this. Private authorities are stored with the user profile and NOT the object. Public authority, object ownership, primary group authorities and an authorisation list name are the only authorities stored with an object.

            Comment


            • tomliotta
              tomliotta commented
              Editing a comment
              Ah, you're right. Not sure what I was thinking at that point.

          • #7
            I think the question of where private authorities are stored has become a little more muddled now that they can be saved with the object in recent releases, using the PVTAUT parameter of the various save commands:

            "Specifies whether to save private authorities with the
            objects that are saved. Saving private authorities will
            increase the amount of time it takes to save the objects,
            but it can simplify the recovery of an object or a group
            of objects. It will not simplify the recovery of an
            entire system."

            Cheers,

            Emmanuel

            Comment


            • #8
              Originally posted by Math555 View Post
              if INLPGM is set and MENU is SIGNOFF, what is the program doing?
              Since we didn't write it, we have no idea what it's doing. You wrote it, so you're the one who knows. (Or someone else at your site wrote it or your site bought it/downloaded it as a product.)

              The point is that it does whatever it was written to do. Perhaps a common thing for it to do is manipulate the job's library list to begin customizing the job's environment for later programs in the job, or perhaps it creates temporary files, or...? It does whatever is intended to be needed 'initially' for the job's user to do his/her work. It might even be the only program that the user is ever allowed to run, perhaps an entire application.

              ...if I have both a set menu and a set initial program, whats the difference? Is there a more risky scenario ?
              "Risky"? It depends... What is the user authorized to do? Risks are directly related to authorities.

              The 'initial' program, if any, runs first, doing whatever it's written to do. When it ends, the 'initial' menu, if any, is displayed. Any authorized options on that initial menu can be taken, and that menu is what the job returns to whenever options end (unless an option causes a different result).

              As already mentioned, authorities can come from wherever the job's processes are able to obtain them. If a program is created for it, it can even be the source of any needed authority. For many applications, program adoption of authority is the preferred source. Users then might need no authority at all except to logon plus authority to run chosen programs. If users have no authority to modify files for example, they can't cause big problems with data even by accident. Only what's written into such programs will happen.

              As also mentioned, there are more paths to risks through network interfaces than through the logon panel for most systems. A user might often do more damage through using Windows Explorer than through logging on with command line access if the server isn't appropriately configured and the user has more authority than needed for the user's work.
              Tom

              There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

              Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

              Comment

              Working...
              X