RE: FTP server authority issue

I don't know what we're disagreeing on - what you said is exactly the
point I was making. IBM should _NOT_ be using CRTPF - especially not the
QSYS qualified version - for the FTP PUT command. It _IS_ a security
loophole, and one that was introduced somewhere between V3R2 and V4R2.
But I _WOULD_ expect that the interface (from the FTP client's point of
view) remains the same from one release of OS/400 to the next.

Tim

> -----Original Message-----
> From: Patrick Townsend [SMTP:townsend@patownsend.com]
> Sent: Sunday, October 18, 1998 10:22 PM
> To:   MIDRANGE-L@midrange.com
> Subject:      Re: FTP server authority issue
> 
> Tim,
> 
> We agree on so much! I suppose we'll have to disagree on this one. I
> think that FTP should not even use the CRTPF command in QSYS for its
> file services. To me the fact that FTP uses CRTPF represents a
> potential
> security hole in FTP and I wouldn't be surprised to see IBM address
> this
> in the future. And as you've already discovered it is dangerous to
> assume that the underlying file interface for FTP will be the same
> from
> one release of OS/400 to another....
> 
> Good luck!
> Patrick
> 
> Tim McCarthy wrote:
> > 
> > Patrick, I don't think you've grasped the issue :-) . Let's say you
> want
> > to change the use of the CRTPF command and create your own - perhaps
> to
> > force some defaults for all users. The way to do this would be to
> > duplicate this command into a library higher in the list than QSYS,
> then
> > you could modify the validity checking program or whatever. Now, to
> stop
> > users from circumventing this and simply using the original version
> (by
> > specifying QSYS/CRTPF) you need to remove the authority of users to
> the
> > version of CRTPF in QSYS. Well once you've done this your FTP users
> are
> > hosed because they can't use PUT anymore because they're not
> authorized
> > to QSYS/CRTPF! No exit point routine will work because it can't
> restore
> > the necessary authority.
> > 
> > > -----Original Message-----
> > > From: Patrick Townsend [SMTP:townsend@patownsend.com]
> > > Sent: Friday, October 16, 1998 1:25 PM
> > > To:   MIDRANGE-L@midrange.com
> > > Subject:      Re: FTP server authority issue
> > >
> > > Tim,
> > >
> > > Interesting. I can sympathize with the desire to have the FTP
> server
> > > use
> > > native AS/400 commands and the library list, but if I were IBM I
> > > certainly wouldn't want to sign up for that restriction. That
> would
> > > prevent them from doing anything to improve performance or
> security at
> > > a
> > > lower level. When you use FTP what you really want is for it to
> obey
> > > all
> > > of the rules (transfer and authority) in the RFCs for FTP, yes?
> > >
> > > Also, if FTP used the library list to resolve the use of the CRTPF
> > > command, wouldn't this introduce the possibility of additional
> > > security
> > > problems? Let's say I'm a creative programmer who knows that
> NEWSYS is
> > > in the system library list above QSYS and that FTP uses CRTPF and
> the
> > > system library list. Wouldn't I be able to create a command called
> > > CRTPF
> > > in NEWSYS that did just about anything I wanted?
> > >
> > > I think that IBM's roadmap for FTP use and security is pretty
> clear.
> > > You
> > > might like or dislike exit points, but I think that's the place to
> > > implement security. If you want a user to execute a CRTPF command
> you
> > > should use the appropriate FTP command to pass this through and
> have
> > > your exit point security module allow or disallow the command.
> > >
> > > Patrick
> > >
> > > Tim McCarthy wrote:
> > > >
> > > > I disagree with your point that FTP commands run on the server
> > > should
> > > > obey a different set of authority rules. If I override certain
> > > commands
> > > > by using a library higher in the list than QSYS and apply
> certain
> > > > authority rules to those commands, I would not expect users to
> be
> > > able
> > > > to circumvent those rules by signing on using FTP instead.
> That's
> > > > effectively what's happening here. PUT is an FTP command but it
> > > utilizes
> > > > OS/400 commands directly - restrictions on the use of CRTPF
> > > inherently
> > > > effect PUT, but users use two different versions of this CRTPF
> > > depending
> > > > on whether they use it directly or through PUT. I too can also
> see
> > > IBM's
> > > > reason for wanting to use a "pure" version of the CRTPF command,
> > > however
> > > > I think using the command directly is the wrong approach -
> > > referencing
> > > > the command authority from the *LIBL while utilizing the QSYS
> CPP
> > > would
> > > > be better. Now the user has a dilemma - authorize everyone using
> FTP
> > > to
> > > > CRTPF in QSYS (what they were trying to prevent) or pre-create
> all
> > > files
> > > > that users PUT to (which is unrealistic in their environment) -
> not
> > > even
> > > > an FTP exit routine will solve this one.
> > > >
> > > > > -----Original Message-----
> > > > > From: Patrick Townsend [SMTP:townsend@patownsend.com]
> > > > > Sent: Friday, October 16, 1998 12:41 AM
> > > > > To:   MIDRANGE-L@midrange.com
> > > > > Subject:      Re: FTP server authority issue
> > > > >
> > > > > Tim,
> > > > >
> > > > > I can see your point about QSTRUPPGM. It is a different class
> of
> > > > > program.
> > > > >
> > > > > I'm a little confused about the issue of creating files via
> put
> > > and
> > > > > crtpf. I can see why IBM would want to force the put command
> to
> > > use
> > > > > the
> > > > > QSYS version of the crtpf command (or any internal version
> that
> > > they
> > > > > want to use). Put is an FTP concept that has to obey FTP
> rules,
> > > not
> > > > > AS/400 rules. If they let you change the way FTP works with
> put it
> > > > > would
> > > > > open up nasty support issues for IBM, wouldn't it?
> > > > >
> > > > > The command interface in FTP lets you run commands that are
> unique
> > > to
> > > > > the particular server. You can execute the crtpf command or
> any
> > > other
> > > > > user-written command you want. No one expects that the command
> > > > > interface
> > > > > will work the same from one platform to another.
> > > > >
> > > > > Am I missing something?
> > > > > Patrick
> > > > >
> > > > > Tim McCarthy wrote:
> > > > > >
> > > > > > But this is not the way it used to work. I've tried this on
> a
> > > V3R2
> > > > > machine
> > > > > > and it uses the library list to determine the command to use
> > > > > (CRTPF).
> > > > > > Whether you are using exit points or not, you still have the
> > > > > exposure that
> > > > > > two different authority levels exist for a single user
> depending
> > > on
> > > > > whether
> > > > > > they attempt a file creation option from the command line or
> use
> > > the
> > > > > PUT
> > > > > > command through the FTP server. (QSTRUPPGM doesn't fall into
> the
> > > > > same
> > > > > > category of program - I would expect it to reference a
> reliable
> > > base
> > > > > set of
> > > > > > commands.)
> > > > > >
> > > > > >
> > > > > > At 12:00 PM 10/15/98 -0700, you wrote:
> > > > > > >Hi Tim,
> > > > > > >
> > > > > > >It is quite common for IBM to qualify command usage to
> point to
> > > the
> > > > > QSYS
> > > > > > >library. Just look at the source for QSTRUPPGM as an
> example.
> > > It
> > > > > would
> > > > > > >probably take an IBM'er to really answer this question. I
> would
> > > > > suspect
> > > > > > >that the proper way to secure FTP is with the exit points.
> Gee,
> > > who
> > > > > do
> > > > > > >we know who has an FTP security product <g> ???
> > > > > > >
> > > > > > >Patrick
> > > > > > >--
> > > > > > >IBM AS/400 communications, FTP automation, and network
> security
> > > > > > >software and consulting services.
> > > > > > >
> > > > > > >mailto:townsend@patownsend.com
> > > > > > >http://www.patownsend.com
> > > > > > >
> > > > > > >Tim McCarthy wrote:
> > > > > > >>
> > > > > > >> Can anyone verify this:
> > > > > > >>
> > > > > > >> A customer is running the OS/400 FTP server under V4R2.
> They
> > > have
> > > > > a
> > > > > > >> modified system library list that has a user library
> NEWSYS
> > > prior
> > > > > to QSYS
> > > > > > >> in which they have created versions of IBM commands - one
> of
> > > > > which is
> > > > > > >> CRTPF. All users have had authority revoked to the
> original
> > > > > commands in
> > > > > > QSYS.
> > > > > > >> When running an FTP session, users authorized to the new
> > > CRTPF
> > > > > command can
> > > > > > >> run the command QUOTE RCMD CRTPF QGPL/myfile etc..
> > > successfully.
> > > > > However
> > > > > > >> when they try to use PUT to send to the file QGPL/myfile
> > > (which
> > > > > does not
> > > > > > >> exist) they get an error "Unable to open or create target
> > > file
> > > > > MYFILE in
> > > > > > >> library QGPL". I've checked out the FTP server job log
> and
> > > the
> > > > > library list
> > > > > > >> does include NEWSYS in the library list ahead of QSYS.
> > > > > Interestingly the
> > > > > > >> server joblog error states "Not authorized to command
> CRTPF
> > > in
> > > > > library
> > > > > > >> QSYS". Has the FTP server program changed to use the
> CRTPF
> > > > > command in QSYS
> > > > > > >> explicitely? If so, this would seem to be a security
> hole.
> > > > > > >>
> > > > > > >> Tim
> > > > > > >> Tim McCarthy
> > > > > > >> TrailBlazer Systems Inc.
> > > > > > >> AS/400 E-Commerce communications
> > > > > > >> +---
> > > > > > >> | This is the Midrange System Mailing List!
> > > > > > >> | To submit a new message, send your mail to
> > > > > MIDRANGE-L@midrange.com.
> > > > > > >> | To subscribe to this list send email to
> > > > > MIDRANGE-L-SUB@midrange.com.
> > > > > > >> | To unsubscribe from this list send email to
> > > > > > MIDRANGE-L-UNSUB@midrange.com.
> > > > > > >> | Questions should be directed to the list
> owner/operator:
> > > > > > david@midrange.com
> > > > > > >> +---
> > > > > > >+---
> > > > > > >| This is the Midrange System Mailing List!
> > > > > > >| To submit a new message, send your mail to
> > > > > MIDRANGE-L@midrange.com.
> > > > > > >| To subscribe to this list send email to
> > > > > MIDRANGE-L-SUB@midrange.com.
> > > > > > >| To unsubscribe from this list send email to
> > > > > MIDRANGE-L-UNSUB@midrange.com.
> > > > > > >| Questions should be directed to the list owner/operator:
> > > > > david@midrange.com
> > > > > > >+---
> > > > > > >
> > > > > > Tim McCarthy
> > > > > > TrailBlazer Systems Inc.
> > > > > > AS/400 E-Commerce communications
> > > > > > +---
> > > > > > | This is the Midrange System Mailing List!
> > > > > > | To submit a new message, send your mail to
> > > > > MIDRANGE-L@midrange.com.
> > > > > > | To subscribe to this list send email to
> > > > > MIDRANGE-L-SUB@midrange.com.
> > > > > > | To unsubscribe from this list send email to
> > > > > MIDRANGE-L-UNSUB@midrange.com.
> > > > > > | Questions should be directed to the list owner/operator:
> > > > > david@midrange.com
> > > > > > +---
> > > > >
> > > > > --
> > > > >
> > > > > IBM AS/400 communications, FTP automation, and network
> security
> > > > > software and consulting services.
> > > > >
> > > > > mailto:townsend@patownsend.com
> > > > > http://www.patownsend.com
> > > > > +---
> > > > > | This is the Midrange System Mailing List!
> > > > > | To submit a new message, send your mail to
> > > MIDRANGE-L@midrange.com.
> > > > > | To subscribe to this list send email to
> > > MIDRANGE-L-SUB@midrange.com.
> > > > > | To unsubscribe from this list send email to
> > > > > MIDRANGE-L-UNSUB@midrange.com.
> > > > > | Questions should be directed to the list owner/operator:
> > > > > david@midrange.com
> > > > > +---
> > > > +---
> > > > | This is the Midrange System Mailing List!
> > > > | To submit a new message, send your mail to
> > > MIDRANGE-L@midrange.com.
> > > > | To subscribe to this list send email to
> > > MIDRANGE-L-SUB@midrange.com.
> > > > | To unsubscribe from this list send email to
> > > MIDRANGE-L-UNSUB@midrange.com.
> > > > | Questions should be directed to the list owner/operator:
> > > david@midrange.com
> > > > +---
> > >
> > > --
> > >
> > > IBM AS/400 communications, FTP automation, and network security
> > > software and consulting services.
> > >
> > > mailto:townsend@patownsend.com
> > > http://www.patownsend.com
> > > +---
> > > | This is the Midrange System Mailing List!
> > > | To submit a new message, send your mail to
> MIDRANGE-L@midrange.com.
> > > | To subscribe to this list send email to
> MIDRANGE-L-SUB@midrange.com.
> > > | To unsubscribe from this list send email to
> > > MIDRANGE-L-UNSUB@midrange.com.
> > > | Questions should be directed to the list owner/operator:
> > > david@midrange.com
> > > +---
> > +---
> > | This is the Midrange System Mailing List!
> > | To submit a new message, send your mail to
> MIDRANGE-L@midrange.com.
> > | To subscribe to this list send email to
> MIDRANGE-L-SUB@midrange.com.
> > | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> > | Questions should be directed to the list owner/operator:
> david@midrange.com
> > +---
> 
> -- 
> 
> IBM AS/400 communications, FTP automation, and network security
> software and consulting services.
> 
> mailto:townsend@patownsend.com
> http://www.patownsend.com
> 
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---