*ALLOBJ and *SECADM
Bkiddo
the authorities *ALLOBJ and/or *SECADM I found these accounts:
MANTUSER *ALLOBJ *AUDIT *IOSYSCFG *JOBCTL *SAVSYS
*SECADM *SERVICE *SPLCTL
ORO *ALLOBJ *AUDIT *IOSYSCFG *JOBCTL *SAVSYS *SECADM
*SERVICE *SPLCTL
QEJBSVR *ALLOBJ *SECADM
QLPAUTO *ALLOBJ *IOSYSCFG *JOBCTL *SAVSYS *SECADM
QLPINSTALL *ALLOBJ *IOSYSCFG *JOBCTL *SAVSYS *SECADM
QOTHPRDOWN *ALLOBJ *SECADM
QPGMR *ALLOBJ *JOBCTL *SAVSYS *SPLCTL
QSYS *ALLOBJ *AUDIT *IOSYSCFG *JOBCTL *SAVSYS *SECADM
*SERVICE *SPLCTL
QTIVROOT *ALLOBJ *AUDIT *IOSYSCFG *JOBCTL *SAVSYS
*SECADM *SERVICE *SPLCTL
RBTADMIN *ALLOBJ *AUDIT *IOSYSCFG *JOBCTL *SAVSYS
*SECADM *SERVICE *SPLCTL
Should I consider it a security concern?
iseriesflorida
I would only be interested in Mantuser, QOTHPRDOWN and ORO. RBTADMIN
is for robot application. The other Q's are IBM id's.
dieter...@t-online.de
QPGMR is not shipped with *ALLOBJ and should not have *ALLOBJ!!!
You should have a look in detail to all of the IBM supplied user profiles,
if they are changed and who has access to this profiles.
Dieter Bender
CRPence
> Checking a system for other acounts besides QSECOFR
> that would have the authorities
> *ALLOBJ and/or *SECADM I found these accounts:
>
> ---------- ------------
> MANTUSER *ALL
> ORO *ALL
> QEJBSVR *ALLOBJ *SECADM
> QLPAUTO *ALLOBJ *IOSYSCFG *JOBCTL *SAVSYS *SECADM
> QLPINSTALL *ALLOBJ *IOSYSCFG *JOBCTL *SAVSYS *SECADM
> QOTHPRDOWN *ALLOBJ *SECADM
> QPGMR *ALLOBJ *JOBCTL *SAVSYS *SPLCTL
> QSYS *ALL
> RBTADMIN *ALL
>
> Should I consider it a security concern?
IMO... Be very much concerned for the security risks several of
those profile present.
The list of IBM-supplied [shipped with OS] profiles and their
expected list of special authorities:
http://publib.boulder.ibm.com/infocenter/systems/scope/i5os/topic/rzarl/rzarlibmsppl.htm
- MANTUSER From its name one might infer this to be a uesr
profile tasked with /maintenance/ activity. See comments about ORO.
- ORO This may be a user profile designated as an
alternate to QSECOFR in the scenario where QSECOFR becomes
unavailable, where it is desirable to have a person able to sign on
and have the same authorities. Thoroughly vet the actual
requirements and ensure that no user has authority to use that
*USRPRF object. Limit or remove the special authorities if need is
not justified. See other comments on other profiles, esp. QOTHPRDOWN
- QLPAUTO Seems fine. Verify normal stuff, like that it has
no password, and no user is authorized; i.e. *PUBLIC *EXCLUDE, and
no private authorities.
- QLPINSTALL Seems fine. Verify normal stuff, like that it has
no password, and no user is authorized; i.e. *PUBLIC *EXCLUDE, and
no private authorities.
- QEJBSVR Seems suspect for both of those authorities. That
profile does ship with the OS, howeer the above doc link fails to
list any special authorities; appearing to be an error in the docs,
rather than an implication it should have none... I am not sure. I
would ask IBM about this one. I suspect as a circumvention to an
authority issue, rather than having the specific issue resolved, the
undesirable method of granting *ALLOBJ was used;;; but *SECADM makes
no sense to me.
- QOTHPRDOWN This is probably the worst offender on the list.
Not only does it have *ALLOBJ & *SECADM special authorities, this is
a 'Q' prefixed object which implies it is shipped by IBM, yet is not
on the list [above doc link]. Be very thorough in determining the
origin of the user profile. Warning... Before any /change/ to the
user, its [special] authorities, get spooled output from DSPOBJD for
both *SERVICE and *FULL, and DSPUSRPRF for *ALL; maybe also
worthwhile DSPUSRPRF for *GRPMBR, *OBJAUT, & ??/ The first two are
most important, as once the object is changed, the previous /last
changed/ information is lost... and that detail may be invaluable to
determine who changed the object last; can be correlated with
auditing. The object information should also show what user created
the profile and when, even what release. As an apparent attempt to
fool someone to go unnoticed, by its naming, this profile deserves
the most immediate and thorough investigation. Note: Web search
results imply this profile might be for LANSA LPP; see comments
about RBTADMIN;; Also: the comments here, irrespective of any
possibility that user belongs to a real product, because it
highlights the subtlety often resulting in failure to notice which
is exploited by hackers.... making something look like it belongs.
As well, if the product no longer exists, the profile should be removed.
- QPGMR Has *ALLOBJ authority! Huge hole which may already
have been exploited. The only valid case for this user having that
authority is for QSECURITY system value being less than 30, which is
in itself problematic; any value other than 40 or 50 are
discouraged. Because QSRV is not on the list, that is unlikely the
origin; instead someone has granted excessive rights. Beyond just
special authorities, the most important information is to know which
users have authority to use these objects. The authority to this
user, with that authority, should
- QSYS This profile is much like QSECOFR [i.e. *ALL] is
expected] although the user is not valid for signon. This profile
should be omitted from any list of concern for having *ALL special
authorities.
- QTIVROOT May be valid, possibly as a Tivoli created profile?
Seems suspect for having *ALL. I do not recall it being a profile
included with the OS, and having all special authorities as a
product profile is probably excessive. Investigate when it was
created, by whom, what it owns and is authorized to, and esp. again,
that no users authorized to this user.
- RBTADMIN This is very likely the ROBOT/400 vendor product
user. Although it probably ships with *ALL special authorities, it
is probably excessive. Consult product documentation [and web?] for
what are the expected authorities, and investigate ownership of
objects. Be especially sure the *USRPRF authorities to other users
is *EXCLUDE; i.e. *PUBLIC *EXCLUDE and no private aurhorities held
by others to that object. Any group members would have valid
authorities [I do not recall which], but any member is similarly
suspect and needs investigation.
Regards, Chuck
Mark
>yes, you have security concerns!
>QPGMR is not shipped with *ALLOBJ and should not have *ALLOBJ!!!
>You should have a look in detail to all of the IBM supplied user profiles,
>if they are changed and who has access to this profiles.
>
>Dieter Bender
I've seen QPGMR given *ALLOBJ by JBA's System 21 software install. Indeed, JBA seemed to
have very little respect for the machine on which it was installed. My other favourite was
the way it would manipulate JOBQ priorities in an effort to leap-frog anything else
waiting in its queue.
Hoepfully this horrible software is now long dead. :)
--
Mark