|
| |
Subject: Re: Problemino durante copie
Newsgroups: it.comp.as400
From: "gandalf" <marco.mellano@its.it>
"Stefano Sonzogni" <sonzogni@sonzogni.it> ha scritto nel messaggio
news:3934cd57.7878298@news.energy.it...
> Ho il seguente problema: nel QEZPWROFFP ho aggiunto una nostra
> procedura che fa i vari salvataggi su nastri e poi esegue un po' di
> reorg e clrpfm su alcuni file temporanei.
>
> Il problema e' che il lavoro viene lanciato dall'utente QSYSOPR che
> non e' autorizzato a cancellare/svuotare i PF nelle varie librerie.
>
> La soluzione migliore secondo voi e' dare l'autorizzazione *ALLOBJ
> all'utente QSYSOPR o esistono metodi migliori o piu' sicuri ?
prova la via dell'adozione delle autorizzazione :
compilalo con un profilo che abbia *allobj (QPGMR?) e, una volta compilato (puo' essere
che sia possibile gia' a livello di compilazione... nun saccio) ci vai su con CHGPGM
PGM(libreria/file) USRPRF(*OWNER) USEADPAUT(*YES)
potrebbe perfino funzionare...
(a quel punto il programma se ne fotte delle autorizzazioni dell'utente che lo lancia...ma
adotta quelle del proprietario: quello che lo ha creato/compilato)
ciao
marco
Subject: Re: RSA ACE/Agents
From: Danilo Cussini <danilocussini@my-deja.com>
"gandalf" <marco.mellano@its.it> wrote:
> sapete se c'e' in giro qualcosa per replicare gli utenti da una macchina all'altra?
bene. Ora aggiusto il tiro. Il problema consiste nel consentire agli account
amministrativi, che giocerellano su una quarantina di as, di cambiare una volta sola la
password e vederla valida per l'intero parco macchine...possibilmente incluse quelle
spente/non in rete in quel momento!
Leggi il manuale "OS/400 Security APIs": ci sono un paio di API che potrebbero
essere interessanti; con Change User Password (QSYCHGPW) puoi cambiare la password, se ne
trovi una per reperirla ... ci puoi
sviluppare qualcosa da eseguire sulle macchine "figlie".
Subject: Re: RSA ACE/Agents
From: Danilo Cussini <danilocussini@my-deja.com>
"gandalf" <marco.mellano@its.it> wrote:
> mica bello cio' che dici: uno dei punti di forza dell'AS e' che non > memorizza
MAI in chiaro le pwd e tu mi vieni a dire di farlo?
> provo a verificare la strada dell'API QSYCHGPW come suggerito dal buon Danilo
Meglio ancora: Retrieve Encrypted User Password (QSYRUPWD) e Set Encrypted User Password
(QSYSUPWD).
Subject: decryptazione password?
From: gandalf <marco_mellano@bigfoot.com>
ciao,
probabilmente lo sapevate gia' quasi tutti ma mi sono imbattuto in
questa pagina e mi sembra il caso di rimbalzarla ai colleghi:
pare che ci sia modo (con 17 righe di codice) di recuperare la
password non cryptata (+ USERID) temporaneamente parcheggiata
nell'area di memoria temporanea.
Mamma', ovviamente, ha gia' rilasciato le PTF del caso...
vi allego l'url il testo della pagina...
ciao
marco
------------------------------------------------------------------------------------------------------------------
http://midrangecomputing.com/mcnetnews/mcnetnews.cfm?mcn=300
For the longest time everyone thought that there was no way to view
unencrypted passwords from the AS/400. But recently an enterprising
programmer discovered a problem with the QDSIGNON screen that would
briefly leave User Profiles and passwords unencrypted in working
memory. Through the use of a deceptively simple 17 line RPG program,
the programmer found that he could capture the User ID and Password of
the last user to signon to the subsystem. The danger in this is that
an unscrupulous programmer could potentially view, in clear text, the
User Name and Password of the last user that signed onto the system.
IBM promptly released PTF's that will fix this problem for all
supported (and several non-supported) releases. The PTF's and their
releases are:
V4R5M0 - SF62896
V4R4M0 - SF62895
V4R3M0 - SF62894
V4R2M0 - SF62946
V4R1M4 - SF62945
V4R1M0 - SF62944
V3R2M0 - SF62947
IBM has always been extremely protective of password security, and was
quite rapid in their response. You are strongly urged to load these
PTF's, or their successors to your system as soon as possible.
At this writing I am not aware of any plans to issue PTF's for any
other release. If you're currently running any other release, this
issue alone should be reason enough to move forward.
Subject: R: decryptazione password?
From: Mauro Mariz <mauro.marizNOSPAM@iol.it>
> ciao,
> probabilmente lo sapevate gia' quasi tutti ma mi sono imbattuto in
> questa pagina e mi sembra il caso di rimbalzarla ai colleghi:
Già, il problema è noto, comunque grazie per la segnalazione.
Quello che mi preoccupa è che non vorrei che OS/400 assomigliasse sempre più
a WinNT.... :-)
bye
Mauro Mariz
3nto
Subject: Re: RSA ACE/Agents
From: Alessandro Monari <monariaOKKIO-ng@dpinfo.it>
Obelix wrote:
>
> On Fri, 16 Jun 2000 15:44:03 +0200, Alessandro Monari
> <monariaOKKIO-ng@dpinfo.it> wrote:
>
> >La routine di
> >controllo password non viene chiamata se faccio un CHGUSRPRF
> Ovviamente, nessuna persona sana di mente lascia a disposizione degli
> utenti CHGUSRPRF...
>
> Obelix
Quindi deduco che mamma IBM non è sana di mente, visto che il CHGUSRPRF ha come
autorizzazione pubblica *USE.
In ogni caso, mi riferivo al fatto che se l'amministratore di sistema modifica
la password per un qualsivoglia motivo utilizzando il CHGUSRPRF, questo non
scatena la routine di cui sopra (che magari, a pensarci bene, è proprio quello
che voglio fare :-)) ).
Subject: Re: RSA ACE/Agents
From: Obelix <nb@unitessile.it>
On Mon, 3 Jul 2000 07:33:44, Alessandro Monari
<monariaOKKIO-ng@dpinfo.it> wrote:
> Quindi deduco che mamma IBM non Š sana di mente, visto che il CHGUSRPRF ha come
> autorizzazione pubblica *USE.
Eri distratto: va messo possibilita' limitate a SI e automaticamente
CHGUSRPRF e' inutilizzabile dagli utenti (security, pagina uno,
paragrafo uno....)
>> che se l'amministratore di sistema modifica
>> la password per un qualsivoglia motivo utilizzando il CHGUSRPRF,
Se lo fai, e' buona regola reimpostare PWDEXP(*YES) in maniera da
forzare l'utente a immettere una *sua* password...
Subject: Re: RSA ACE/Agents
From: Alessandro Monari <monariaOKKIO-ng@dpinfo.it>
[zip]
> Eri distratto: va messo possibilita' limitate a SI e automaticamente
> CHGUSRPRF e' inutilizzabile dagli utenti (security, pagina uno,
> paragrafo uno....)
[zap]
E tu sei fortunato. Riesci a creare profili utente con LMTCPB(*YES).
Qui da noi (e non credo solo qui) è improponibile (quasi tutti programmatori).
Concordo sulla seconda.
Ciao.
Subject: Re: RSA ACE/Agents
From: Obelix <nb@unitessile.it>
On Mon, 3 Jul 2000 10:46:50, Alessandro Monari
<monariaOKKIO-ng@dpinfo.it> wrote:
> Qui da noi (e non credo solo qui) Š improponibile (quasi tutti programmatori).
In quel caso (ma e' una eccezione...) si va di EDTOBJAUT.... ma, ripeto, non e' il
default...
Subject: Re: RSA ACE/Agents
From: HK <h@k.it>
> In ogni caso, mi riferivo al fatto che se l'amministratore di sistema modifica
> la password per un qualsivoglia motivo utilizzando il CHGUSRPRF, questo
> scatena la routine di cui sopra (che magari, a pensarci bene, è proprio quello
> che voglio fare :-)) ).
E' possibile scrivere un exit program per intercettare (e validare) inserimenti, modifiche
e cancellazioni di *USRPRF, oltre a tante altre belle cosette:
WRKREGINF EXITPNT(QIBM_QSY*)
Subject: buco nella sicurezza e PTF
From: gandalf <marco_mellano@bigfoot.com>
NewsGroup: it.comp.as400
Date: martedì 1 agosto 2000 13.37
siccome non ho visto niente in proposito di qua, mi permetto di
ruotare un messaggio da comp.sys.ibm.as400.misc che ritengo
interessantissimo....
marco
ORIGINAL EXPOSURE:
There is ANOTHER hole in OS/400 Security...
To me this is MUCH worse then the one last month for 2 reasons:
(1) It is easy to do and ANYONE with QPGMR in their user profile can
do
it !!
(2) It gives you access to EVERYONE's password who is signed on at the
time (the way last month only gave you the LAST person to sign on...)
!!!
===========================================================================
DMPSYSOBJ still displays cleartext passwords after last month's
security
PTF is applied, and still works on level 40 and 50. Two steps are
needed. First dump the subsystem device table. For example the
following will dump the device table in subsystem QINTER in library
QSYS:
DMPSYSOBJ OBJ(QINTER) +
CONTEXT(QSYS) +
OBJTYPE(*SBSD) +
OFFSET(190)
This will generate a spooled file of device names. Scan the spooled
file for the 10-character device name you want to sniff (e.g. DSP96).
When you find it, look to the left for the 'Offset in Space' number,
and
add X'80'. For example if the device name appears in dump line
X'F9E0',
then:
X'F9E0'
+ X'0080'
---------
X'FA60'
Use this result as the second OFFSET number in another DMPSYSOBJ, for
example:
DMPSYSOBJ OBJ(QINTER) +
CONTEXT(QSYS) +
OBJTYPE(*SBSD) +
OFFSET(190 FA60 60 40) +
SPACE(6 1A)
If the target workstation is signed on, this generates a spooled file
showing the username and cleartext password.
============================================================================
=====
The BAD thing is the DMPSYSOBJ has *USE for QPGMR so ANY programmer
could be doing this/could have already done this...
When you look at the FIRST printout, the "Offset in Space field
mentioned is the FIRST field on the line with the Device ID...
Here are the PTF numbers for the newest password fix.
V3R2 SF63352
V4R1 SF63350
V4R1M4 SF63351
V4R2 SF63357
V4R3 SF63347
V4R4 SF63349
The developers told me that all these PTFs, except for V4R1M4, were
approved today. That means you can order them now. The V4R1M4 PTF
should
be available by the end of the day or sometime tomorrow. It looks
like
a
V4R5 PTF will be available on or before Friday.
Subject: R: buco nella sicurezza e PTF
From: Mauro Mariz <mauro.marizNOSPAM@iol.it>
NewsGroup: it.comp.as400
Date: mercoledì 2 agosto 2000 9.13
Da NewsWire/400:
DEFECTIVE PTF
============
IBM's latest round of PTFs for correcting a serious password security
exposure -- which we reported to you last week -- are defective. In
addition to addressing the security exposure, these PTFs addressed
several display file issues. As luck would have it, there were
problems with the code for some of these other display file issues,
and applying these PTFs could cause display file problems.
Following is a list of previously recommended PTFs:
V3R2 - SF63352
V4R1 - SF63350
V4R1M4 - SF63351
V4R2 - SF63357
V4R3 - SF63347
V4R4 - SF63349
IBM has marked all of the V4 PTFs listed above as defective. IBM
hopes to have replacement PTFs that address only the security
exposure available soon. For now, IBM suggests that customers ensure
command DMPSYSOBJ is sufficiently restricted. Of course, this does
nothing to prevent a program from accessing the same information. If
you've temporarily applied these PTFs, you should consider removing
them to avoid display file problems. Watch here for updated PTF
information as it becomes available.
bye
Mauro Mariz
3nto
|