Re: iSeries FTP security

[Evan Harris <spanner@xxxxxxxxxx>]

Hi Patrick

While I don't disagree with your general point that allowing access to data 
to an authorised user cannot be considered a security exposure inherent in 
the system, I think on the whole I have to agree with Rob here; I, too, 
appreciated hearing about this method of circumventing security. Security 
that can be circumvented would seem to me to be fairly termed an exposure. 
The view I take is that in this case the access methodology is not an 
"approved" access method and that the intent has been to lock it down using 
an exit point to control access.

Unless I read it wrong, the identified exposure reveals how the intended 
exit point restriction can be evaded by manipulating the path to navigate 
to supposedly forbidden directories unless this has been explicitly catered 
for in the exit point program code. The API manuals as I recall them do not 
provide any guidance as to how to code for this type of path manipulation 
and in some eyes this might be considered a weakness or oversight.

Due to this, it seems to me that this is a useful thing to be aware of, 
particularly when trying to lock down a system that has a weak security 
model such as many iSeries shops have for historical reasons of relying on 
menu based security. The usual approach to trying to secure a machine with 
one of these security models is to use the exit points to overcome the 
inadequacies of the menu based strategy.

I do agree that the optimum solution is to move to a better security model 
but for many sites this is not always practical.

Regards
Evan Harris

At 11:04 a.m. 17/05/2005, you wrote:
> I agree that telling customers that the only way to effectively control
> access to data on the system is by using the native object access control
> mechanisms is a very useful service. The fact that many customers don't is a
> HUGE and very serious issue.
>
> I do believe, however, that the author either by design or by accident
> incorrectly identifies the source of the problem. Announcing every user
> interface that can be used to access data by an authenticated and
> authorizeduser is a disservice. The author's language is such that he
> focuses on the
> interface used to access authorized data rather than the fact that all
> authenticated users are allowed to access most data.
>
> This is not a security exposure inherent in the system. It is an exposure in
> either the customer's security policy or his/her implementation of it. Yes,
> it's a huge problem, but there is nothing the system can do to prevent an
> authenticated user from accessing data to which he/she is authorized.
>
> If the author would focus on publicizing the real issue, the greater the
> likelihood that fewer people will be confused and ignore the warnings.
>
> On 5/16/05, rob@xxxxxxxxx <rob@xxxxxxxxx> wrote:
> >
> > Frankly I think it was a good service to publish this so that I may fix my
> > code. And, yes, users who are supposed to ftp files from/to our 400
> > should have ftp access. It isn't that hard to write a program to lock
> > this down. But with "heads up" notifications from people like this, you
> > can fix it before someone exploits your mistake.
> >
> > Rob Berendt