Midrange News for the IBM i Community


Posted by: Bob Cozzi
Rogue Programmer
Cozzi Productions, Inc.
Chicagoland
Is the Basic Job Schedule a Security Hole?
has no ratings.
Published: 09 Nov 2012
Revised: 23 Jan 2013 - 1639 days ago
Last viewed on: 19 Jul 2017 (3102 views) 

Using IBM i? Need to create Excel, CSV, HTML, JSON, PDF, SPOOL reports? Learn more about the fastest and least expensive tool for the job: SQL iQuery.

Is the Basic Job Schedule a Security Hole? Published by: Bob Cozzi on 09 Nov 2012 view comments(13)

It just occurred to me that I can add a job scheduler entry (ADDJOBSCDE) and specify a user profile under which the scheduled job will run.

What if specify QSECOFR or another "powerful" user profile as the user profile?

What if the program that will be run is a CL program that changes "my" user profile to *ALLOBJ?

I may have to try this at home.

Return to midrangenews.com home page.
Sort Ascend | Descend

COMMENTS

(Sign in to Post a Comment)
Posted by: bobcozzi
Site Admin ****
Chicagoland
Comment on: Is the Basic Job Schedule a Security Hole?
Posted: 4 years 8 months 10 days 5 hours 5 minutes ago

Wow, that's unfortunate. It actually did exactly what I expected... it changed my authority. So there you have it. Put a command on the job scheduler as USRPRF(QSECOFR) and it'll run it as QSECOFR.  

There must be something else blocking this kind of thing... right?

Posted by: BrianR
Premium member *
Green Bay, WI
Comment on: Is the Basic Job Schedule a Security Hole?
Posted: 4 years 8 months 10 days 4 hours 53 minutes ago

When I tried to add a job schedule entry running under QSECOFR without having authority to that user profile, it gave me a Not authorized to user profile QSECOFR message and wouldn't let me add the entry.

Posted by: bobcozzi
Site Admin ****
Chicagoland
Comment on: Is the Basic Job Schedule a Security Hole?
Posted: 4 years 8 months 10 days 4 hours 34 minutes ago
Edited: Fri, 09 Nov, 2012 at 22:12:55 (1714 days ago)

Good to know. I'm not supposed to be able to change my own SPCAUT settings, however. But I was able to using the above technique. I must have authority to QSECOFR, but I don't know what "authority to QSECOFR" means, specifically.

Posted by: Ringer
Premium member *
Comment on: Is the Basic Job Schedule a Security Hole?
Posted: 4 years 8 months 10 days 3 hours 57 minutes ago

Yes, the job scheduler allows this, a Q user profile, unlike SBMJOB which does not allow them.

Chris Ringer

Posted by: TFisher
Premium member *
Comment on: Is the Basic Job Schedule a Security Hole?
Posted: 4 years 8 months 7 days 20 hours 54 minutes ago

It depends on how security is setup on your system.  On one system I have no authority to other profiles so I cannot do it.  On another I was able to schedule a job as another user and grant myself *ALLOBJ authority.

Posted by: DaleB
Premium member *
Reading, PA
Comment on: Is the Basic Job Schedule a Security Hole?
Posted: 4 years 8 months 7 days 9 hours 59 minutes ago

See the help for both ADDJOBSCDE and SBMJOB. For USER keyword on ADDJOBSCDE, you need *USE to the user profile that the job is to run under.

Posted by: bobcozzi
Site Admin ****
Chicagoland
Comment on: Is the Basic Job Schedule a Security Hole?
Posted: 4 years 8 months 7 days 8 hours 48 minutes ago

Dale, yes, but I think this may be design flaw... Fish and I shouldn't have been able to do anything more than we normally would using a compiled CL program that we write/create.

Posted by: DaleB
Premium member *
Reading, PA
Comment on: Is the Basic Job Schedule a Security Hole?
Posted: 4 years 8 months 7 days 6 hours 42 minutes ago

The flaw is that you were granted *USE to QSECOFR (or other powerful user). Shame on your security officer. If you're in a public company, the auditors should be checking this.

Posted by: bobcozzi
Site Admin ****
Chicagoland
Comment on: Is the Basic Job Schedule a Security Hole?
Posted: 4 years 8 months 7 days 4 hours 39 minutes ago

Not public.

Posted by: TFisher
Premium member *
Comment on: Is the Basic Job Schedule a Security Hole?
Posted: 4 years 8 months 5 days 8 hours 30 minutes ago

I doubt most SOX auditors would know anything about this.  There are plenty of "back doors" built right into the system.  For example, we are not suppose to have access to a command line on our production machine. But, we are allowed to have query and SQL due to most of our database files being secured.  When I need a command line I go into my STRSQL option and type 'CALL QCMD'.

Posted by: neilrh
Premium member *
Jackson, MI
Comment on: Is the Basic Job Schedule a Security Hole?
Posted: 4 years 8 months 3 days 9 hours 58 minutes ago

Isn't there also protections that you cannot compile a program containing commands that you are not authorized to. This has prevented me from creating utility programs in the past, because SECOFR had the system locked down so tightly. But then while this can prevent you from creating a CL, there's no block on compiling a program with commands that are executed through QCMDEXC.

Posted by: DaleB
Premium member *
Reading, PA
Comment on: Is the Basic Job Schedule a Security Hole?
Posted: 4 years 8 months 3 days 9 hours 37 minutes ago

True - if you are not authorized to a command, you cannot compile a CL program containing that command. But with QCMDEXC you're not actually referencing the command at all - the command is just content in a *CHAR variable. So, with QCMDEXC, the authority to the command that's in the QCMDEXC parameter won't be checked until you try to run it.

Here's another little quirk - You don't need to be authorized to the *CMD's command processing program, PGM(). Ran this past IBM at one point. Turns out when you try to run a command, the system checks object authority on the *CMD, but does not check any authority on the PGM() behind the command. It's only that first *PGM, though. It doesn't extend to objects referenced from the program, such as files, calls to other programs, etc. Not sure about PGM(*REXX), but I'd hazard a guess that it will ignore authority on the REXX source *FILE.

Posted by: bobcozzi
Site Admin ****
Chicagoland
Comment on: Is the Basic Job Schedule a Security Hole?
Posted: 4 years 8 months 3 days 8 hours 27 minutes ago

Dale, so that could mean that some shops where copying the original IBM i CL Commands from QSYS to a user library and changing their defaults, could also provide a backdoor to that function. For example if you lockdown PWRxxxSYS and there's a dup of it, that Dup's authority is all that is tested when that copy is being run?