|
Ummmm... A couple of clarifications... I've been corrected here. Tom Liotta pointed out that a DSPOBJD FRED would either display the "Not Authorized" message, or display an object called Fred that I am authorized to and was higher in my library list than the one I was *excluded from. Also, Steve Martinson pointed me to the BugTraq thread of 2/25 where you all had already covered these points in detail. I missed that thread because I was somewhere warm and sunny and had a potent mix of Corona, Tequila, and Salsa circulating through my system. It was tough, but somebody had to do it. :) jte -- John Earl www.powertechgroup.com john.earl@powertechgroup.com The Powertech Group Inc. Seattle, Washington Where the Security Experts Live! Phone: +1-253-872-7788 (optional) Fax: +1-253-872-7904 (optional) -- ----- Original Message ----- From: "John Earl" <john.earl@powertechgroup.com> To: <midrange-l@midrange.com> Sent: Wednesday, March 06, 2002 4:39 AM Subject: Re: OS/400 User Account Name Disclosure Vulnerability > Ed, > > Well argued. I don't think that this quirk represents a serious security > exposure, but it is interesting from the following perspective: > > As soon as I give someone *USE authority to a library I have given them the > ability to see, and verify the existence of, all objects in that library - > even if the user's authority to the individual object is *EXCLUDE. If this > is not a shortcoming of security, it is at least inconsistent. If I issue > the command "DSPOBJD FRED" or "WRKOBJ FRED" from a command line, I will not > see any object named "FRED" in my library list if my authority to those > objects is *EXCLUDE. Yet, If I access a 'list library' procedure, I would > be eligible to see and verify the existence of all of the objects named > "FRED" (not just User Profiles) in that library - regardless of my authority > to said objects. > > What this means to me is that I can not conceal the existence of an object > from a user if the object exists in a library the user has *USE authority > to. If you have a business reason to conceal the existence of objects from > certain users, you'll need to put that object in a library that those users > have *EXCLUDE authority to. Not necessarily an out and out security > exposure, but it is new news to me. > > > jte > > > > -- > John Earl > www.powertechgroup.com john.earl@powertechgroup.com > The Powertech Group Inc. Seattle, Washington > Where the Security Experts Live! > > Phone: +1-253-872-7788 (optional) > Fax: +1-253-872-7904 (optional) > -- > ----- Original Message ----- > From: "Ed Fishel" <edfishel@us.ibm.com> > To: <midrange-l@midrange.com> > Sent: Tuesday, March 05, 2002 10:53 AM > Subject: Re: OS/400 User Account Name Disclosure Vulnerability > > > > > > Here are some of my opinions on this topic. > > > > 1. Is it a security exposure to know the name of other user profiles on > the > > system? > > > > No. If it is a security problem to know the names of all the user profiles > > on the system then it must be a problem to know the names of some user > > profiles, or even one other user profile. In my opinion, those people that > > want to prevent some users from finding the names of other user profiles > on > > the system are practicing a form of security by obscurity. The system is > > designed to compete in the business environment where knowing the name of > > other users on the system is allowed. > > > > Knowing, or guessing the name of a user profile is not a security problem, > > but being able to sign-on and use that user profile would be a problem. > > Good security design requires that even thought a user knows the name of a > > user profile, that cannot easily guess the password of the user profile or > > even know any other information about that user profile. > > > > 2. Do other systems allow users to find the same level of information? > > > > Yes. At least all Unix systems I am aware of allow any signed-on user to > > get a list of all users on the system by using a command such as: cat > > /etc/passwd | scroll > > > > Ed Fishel, > > edfishel@US.IBM.COM > > > > _______________________________________________ > > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing > list > > To post a message email: MIDRANGE-L@midrange.com > > To subscribe, unsubscribe, or change list options, > > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > > or email: MIDRANGE-L-request@midrange.com > > Before posting, please take a moment to review the archives > > at http://archive.midrange.com/midrange-l. > > > > _______________________________________________ > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > or email: MIDRANGE-L-request@midrange.com > 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.