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



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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.