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



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