|
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 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.