Thanks to everyone who responded. You all raised some serious issues
that I need to think about.
Original post was:
I have an application in which the customer wants us to verify the user's
identity by having him enter a password. To avoid confusion, I would like
to have this password be the same one that the user logged in with. I know
that I could encrypt the password and compare it to the value returned by
getspnam, but this would require that the calling program have system privileges
(suid). Is there any other way to do this?
The situation, by the way, is complicated by the fact that the application is
written in Oracle forms. This means that I will need to link the password
checking function into a shared library and call it as a plsql foreign function.
Summary:
One response cautioned against using login passwords for application
purposes and I can see the point. Since all application users
have captive sessions with no access to a shell, however, I think that
the risk here is minimal. Having the application maintain its own
password table containing passwords which may be identical or similar
to login passwords also raises security issues. Also, if users have to
remember two passwords, they are more likely to write them down.
My most likely approach will be to have a server process which runs
as root and services requests for password verification from
the application. The server would obtain the requestor's id from the
operating system in order to insure that we don't have any rouge
processes out there trying to guess passwords which belong to other users.
The server will be accessable only to processes running on the host
system, so network accesses should not be an issue.
Responses:
From: Rich Kulawiec <rsk@itw.com>
Yes, you can do that, and you can probably grab the code from a lot of
places, like Crack 5.0. You could probably isolate the comparison code
into a small program run as a subprocess to minimize the amount of
code that needs to be setuid (I'm presuming you're using a shadow
password file).
However, I would advise you in the strongest possible terms that reusing
a login password for an application is a terribly bad idea. It's likely
to open up a lot of security holes, since the security of your login passwords
will now be tied to the integrity of your application. And unless you
have a very small, heavily-tested application, it's very difficult to
secure those passwords. I would suggest that users be issued different
passwords (application-specific). Those users who can't deal with that
are probably users who should not be attempting to use computer systems.
---Rsk
Rich Kulawiec
rsk@itw.com
=======================================================================
From: Francisco Franco <ffranco@interlog.com>
If you are running your SQL*Forms application on the box why don't you
explore the "ops$account_name" function in Oracle.
It might be what you are looking for. "ops$" accounts in Oracle allow
the user to log into the application after they have already signed into
the box. It more or less lets the box (UNIX/VMS that's the only experience
that I have with "ops$") do the password validation for you. It assumes
that once you have gained access to the box, you are the valid user.
Pleae let me know if you need additional info.
My note:
The point of asking the user for a password was to verify that this
was the same user who had logged on originally, not someone else
who had just walked up to a logged on terminal.
=======================================================================
From: Michael Scoltock <scoltock@ictp.trieste.it>
I don't know if this solution is feasible for your application, but you
could use a facility in Oracle which is for this sort of situation. Rather
than having to login to Oracle, you can allow Oracle to assume that the
Unix login is valid. By launching SQL*Forms like this 'runforms /', Unix
user 'fred' can be logged into Oracle as user 'OP$FRED' (the OP$ prefix is
an Oracle system parameter, which can even be a null string, as is the
possibility to allow this sort of login) without giving _any_ password. The
user only has to give his password when he logs into Unix, Oracle is then
delegating the security to Unix.
The alternative you outlined would have the drawback not only of having to
put some sort of wrapper around runforms, but also of keeping aligned the
Unix password with the Oracle password.
I hope this is helpful. Good luck,
Mike Scoltock
=======================================================================
From: peter.allan@aeat.co.uk (Peter M Allan)
Using shadow passwords I suppose.
How about using a ready-made suid prog "su" ?
Can your Oracle do this with a clean environment ?
$ /bin/su username -c /bin/true
Password:
$ echo $?
0
This will clog up your syslog.
-- Peter Allan peter.allan@aeat.co.uk
=======================================================================
From: Michael van Dijk <mvd@wcomp.gov.za>
We have more or less similar problems. If I can give you a few of the options
we use:
1. Use the Oracle facility for user validation against the OS. I don't know
if you know how to do this, but I'll try to explain briefly:
- the user is created on UNIX as normal
- the user is created in Oracle as OPS$USER (check your parameter
OS_AUTHENT_PREFIX in init.ora) identified EXTERNALLY
- the user is the authorized to used Oracle as soon as he is logged into
UNIX
However, I don't think this answers your question!
2. If you create the user in the normal way, i.e. having a password in both
UNIX and Oracle, firstly you'll have to synch them and against which one
are you going to authenticate (Should they NOT be synch'ed)? This also
makes it fairly difficult to provide your user with the facility to change
his own passwd.
3. You can do the above, with standard UNIX and Oracle passwds (try and make it
transparent). The application can then authenticate the user itself. You can
also make initial logon to the app transparent. (The auditors don't like this!)
4. We use option #1 plus:
- the (client-server) apps have additional functionality which enables users
to change their own passwds. These functions and the UNIX server are custom
written.
- The only way we (outside of the US) can authenticate the passwd, is to encrypt
the entered one and compare it to the already encrypted one from getspnam
(char *sp_pwdp). I use crypt(3C) and des_crypt(3C) for this.
- I just can't seem to remember the exact Oracle function for this, but you
could also try this in Oracle in a similar way.
Hope it helps
Michael
----------------------------------------------------------------
Michael van Dijk +27 (0)12 319-9248 [W]
mvd@wcomp.gov.za +27 (0)82 891-9458 [Cell]
SysAdm / DBA Xcel Engineering & Management (Pty) Ltd
----------------------------------------------------------------
=======================================================================
From: Grinnell_Rick/goc_openmail@fpc.com
Item Subject: Use of passwords in an application program
Youd only have to run suid if you are using a shadow password file -
which I presume you are. I have done similar things by writing
client/server code, fired by inetd.conf listening on a specific port.
The service gets fired by root, so isn't suid. The advantage here is
that we can have generic clients (web-enabled?) modify/verify their
passwords on all unix hosts, including OracleDBs from a single desktop
gui or browser. It also does verification based upon the login ID.
Unfortunatley I cant speak Oracle forms
=======================================================================
From: raju@ecologic.net
How about something like this:
1) Leave the system password file alone (/etc/passwd)
2) Create a password file of Oracle users (/etc/opasswd or something)
make the owner root and group the same as the effective group that
your calling program will run as. The format of this file is up to
you, you might just need the login and password and not the other
stuff in /etc/passwd
3) Set the file permissions of 640
4) Write a setuid wrapper around /bin/passwd that does the following
- Figures out who we are changing the password for ('passwd' as
opposed to 'passwd <user>' for example)
- Execs /bin/passwd and checks the exit status. On failure do nothing
- Otherwise, check to see if the user is also an Oracle user (by looking
in /etc/opasswd for the login name), if it is, get the encrypted
password string from /etc/shadow and update /etc/opasswd.
5) (optional) Write a wrapper for /usr/sbin/useradd that passes all
it arguements to 'useradd' and also takes another arg (-O maybe)
that will make a blank entry in /etc/opasswd.
6) (optional) Write a wrapper for /usr/sbin/userdel that will check
for the username in /etc/opasswd and delete it if it exists.
There are a few problems/implications that you might want to consider:
1) This system is fairly complicated and does a lot of privileged operations,
making it inherently dangerous. You will have to be very carefull in
writing the wrapper for /bin/passwd
2) By creating another password file, you are in some effect, defeating
the purpose of shadow passwords, to minimize the risk, make sure that:
- That the file is, at most, group readable.
- Make sure that as few people as possible belong to the group. I assume
in Oracle, functions execute as a particular user or, atleast with
particular group privileges, in which case, only that user or
users should belong to the group.
- Only include logins and passwords that are required.
- Inform those users of what you are doing and that they should
start changing their password more often than they normally do.
3) You might have other programs that modify /etc/passwd, in which case,
you will need to wrap/modify those programs too.
Well, I hope this helps, or atleast give you some ideas,
--raju
Raju Krishnamurthy - Senior Software Engineer
=======================================================================
From: "Matthew J. Hill" <MHILL@graver.com>
one trick is to make another user 'shadow', have /etc/shadow owned by
user shadow with mode 400... this way all root processes can still
access it (they can get to anything) and you can make programs such
as yours suid shadow, which gives them no additional privliges,
except that they can access the shadow file.
-- Matthew J. Hill hill@graver.com=======================================================================
Peter Schauss ps4330@okc01.rb.jccbi.gov Gull Electronic Systems Division Parker Hannifin Corporation Smithtown, NY
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:44 CDT