× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Do symbolic links not care about the security on the actual file?  I 
thought of symbolic links much like logical files.  And, I guess I 
remember there is a way to secure a physical file to not allow direct 
access but only allow logical file access to it.  This was how some people 
did field level security before the latest versions of OS supported that.

So, if I create a user named FTPUSER and his home directory is /ftpuser 
and (here's the HUGE if) if I put him as *EXCLUDE in every other directory 
on my system, then if I create a symbolic link in /ftpuser that points to 
a file in /mydir then they could access that file?  That might be doable, 
if so how do I have to do anything funny in the security on the requested 
file in /mydir?  Like:
CHGAUT OBJ('/mydir/myfile.csv') DTAAUT(*NONE) OBJAUT(*OBJREF)
But I still have the huge concern of making sure that FTPUSER has *exclude 
on every other directory.  Then I guess any ftp exit point would only be a 
defense-in-depth.

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





"Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
05/17/2005 07:22 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
"'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
cc

Subject
RE: iSeries FTP security






> From: Evan Harris
> 
> Hi Patrick
> 
> 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.

Here's an interesting take on it: you might want to understand how FTP
works before you open up your mission critical machines to it.
Seriously, the ".." exploit is known to just about every script kiddie
who ever set up an FTP server only to see somebody go rifling through
their files.  The problem is not that the iSeries is allowing access,
but that people are allowing FTP access to their iSeries without really
knowing how FTP works.

Every time somebody posts something about how they "must" allow FTP
access, or "must" allow ODBC access to their data, I cringe because I'm
almost certain that they haven't gone out and investigated how these
utilities work.  There are similar exploits with ODBC too numerous to
mention, especially for people with authorized access to your machine.

The right answer is to create separate, low-access user profiles with
access only to sandbox areas, and then to put data in those areas only
on demand.  Unfortunately, some of those same people who are opening
their machines to ODBC and FTP access will be the first to say this is
too much work.

Anyway, my .02 on this is that you need to know how the tools work,
warts and all, BEFORE you implement them.  The ".." technique is a good
one to guard against, and I guess if you have to learn it from the guy
in question, then that's better than nothing.  But you might want to
talk to a local twelve-year-old before you open your production data to
FTP access.

Joe

P.S. Among the many ways around this particular issue is to a create
special IFS folder with limited access and disable access to that
folder's parent folder, then create symbolic links to the data in
question.

-- 
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.