authenticating to ASE without using a password

[Hermooz]

Hi all!
I have an ASE 15 on a RHEL 5.1. I would like to create some
administrative shell script to automate some tasks, and I'm not very
fond of saving account passwords in those. I was looking for a way, if
it exists, to set up a sort of OS-integrated authentication, similar
to the "trusted" connection of MS-SQL server or the "internal"
connection of Oracle, so to say.
I initially tought that PAM integration could permit such a setup, but
after some experimentation it looks like I still have to provide a
password to "isql" to access the DB; I've been able to connect without
one with the -V switch, but only in interactive mode, and still
getting an error by CT-LIBRARY.
Can someone point me in the right direction?

Best regards,
Fabrizio

[michael...@gmail.com]

The only other technique that I know of means using Kerberos
(something that I haven't used myself).

You may want to look it up in the Sybase manuals.

Michael

[Hermooz]

On Apr 24, 10:56 am, "mpepp...@peppler.org"
<michael.pepp...@gmail.com> wrote:

> The only other technique that I know of means using Kerberos
> (something that I haven't used myself).
> You may want to look it up in the Sybase manuals.

First of all thanks for your reply, Michael. Yes, I've seen the
"kerberos way" in the manual, but I'm afraid that would be a little
too complicated since I don't have a kerberos server to use (and
implementing a Kerberos infrastructure on purpose for a couple of
scripts looks like an overkill).
Now there's another thing that worries me: as I said I was
experimenting using the -V switch of the isql utility to try to
connect without password... and I've discovered that using that switch
ANY user can connect to ASE without password, in interactive mode, and
gets SA rights! I'm pretty sure that this is NOT intended behaviour.
Have you ever heard of this?

Best regards,
Fabrizio

[Thomas Gagne]

The 'is' program has a -C command-line option that tells it to use environment variables for the username/password/server settings.  The documentation explains it like this:

-C    Examine the environment variable HTTP_COOKIE.  Modifies the
        meaning of -U, -P and -S.  If -C is supplied, the arguments
        to -U, -P, and -S can be the names of other environment
        variables to use for username, password, and server.

So if you have another secure way of setting environment variables you could do something lik:

setenv HTTP_COOKIE
setenv SNEAKYNAME sa
setenv SNEAKYPASS mySecretPassword

Then the command line would look like: 'is -C -USNEAKYNAME -PSNEAKYPASS'

is can be found at <http://gagne.homedns.org/~tgagne/is/>

-- 
Visit <http://blogs.instreamco.com/anything.php> to read 
my rants on technology and the finance industry.  Visit
<http://tggagne.blogspot.com/> for politics, society and culture.

[SybaseNeal]

Hello,

What version of ASE are you using (select @@version)?

What version of ISQL are you using (isql -v)?

What is the exact syntax you are using with ISQL?

Here is what I tried:
% isql -Usa -P -V
CT-LIBRARY error:
ct_connect(): security service layer: internal security control layer error: Consistency checks performed on the credential failed (minor status 0).

% isql -V
CT-LIBRARY error:
ct_connect(): security service layer: internal security control layer error: Consistency checks performed on the credential failed (minor status -1765328189).

Thanks,
Neal

[michael...@gmail.com]

On Apr 24, 3:31 pm, Thomas Gagne <tga...@wide-open-west.com> wrote:
> The 'is' program has a -C command-line option that tells it to use
> environment variables for the username/password/server settings. The
> documentation explains it like this:
>
> -C Examine the environment variable HTTP_COOKIE. Modifies the
> meaning of -U, -P and -S. If -C is supplied, the arguments
> to -U, -P, and -S can be the names of other environment
> variables to use for username, password, and server.
>
> So if you have another secure way of setting environment variables you
> could do something lik:
>
> setenv HTTP_COOKIE
> setenv SNEAKYNAME sa
> setenv SNEAKYPASS mySecretPassword
>
> Then the command line would look like: 'is -C -USNEAKYNAME -PSNEAKYPASS'
>

This is certainly useful for certain situations, but the ps command
lets you list the env. variables of a process, so the password *could*
be discovered by a user with even relatively minimal rights on the
system.

The best technique that I've found is to have a file that has the
password, that is owned by the user running the scripts (probably the
"sybase" account), and setting the access rights to the file to 0400
so that it is only readable by the user and root. It's still not
perfect, though.

Michael

[Hermooz]

On Apr 24, 3:32 pm, SybaseNeal <nst...@nospam.com> wrote:
> Hello,

Hi Neal!

> What version of ASE are you using (select @@version)?

Adaptive Server Enterprise/15.0.2/EBF 15659 ESD#4/P/x86_64/
Enterprise Linux/ase
1502/2528/64-bit/FBO/Sat Apr 5 05:40:36 2008

> What version of ISQL are you using (isql -v)?

Sybase CTISQL Utility/15.0/P-EBF14165 ESD #7/DRV.15.0.3/Linux Intel/
Linux 2.4.21-47.0.1.ELsmp i686/BUILD1500-093/OPT/Wed Dec 13 21:49:08
2006

(however the isql version was not relevant; we observed the same
behaviour also with a windows sybase 12 client...)

Ah, and we are on a vanilla RHEL 5.1 on x86_64.

> What is the exact syntax you are using with ISQL?

isql -Sserver -V

> Here is what I tried:
> % isql -Usa -P -V
> CT-LIBRARY error:
> ct_connect(): security service layer: internal security control layer error: Consistency checks performed on the credential failed (minor status 0).

Yes, this is - I think - expected behaviour.
I've done more testing with my colleagues and we have discovered more
info.
The problem was caused by, apparently, some communication problem
between the PAM library and ASE server. It has started when I created
an "ase" service in the pam.d directory of our service, following
directions from sybase manual, containing the row:

auth required pam_unix.so

Now, when we tried to connect with the -V option, sybase was
delegating access control to the PAM module; of course, since we did
not supply a regular account, PAM responded with a failure, and we
could see this in "secure" log:

Apr 23 18:36:29 itflosyb0099 dataserver: pam_unix(ase:auth): check
pass; user
unknown
Apr 23 18:36:29 itflosyb0099 dataserver: pam_unix(ase:auth):
authentication fa
ilure; logname= uid=500 euid=500 tty= ruser=sa rhost=itflosyb0099
Apr 23 18:36:29 itflosyb0099 dataserver: pam_succeed_if(ase:auth):
error retri
eving information about user sa

note that apparently ASE defaults to "sa" user if none is specified.
The worst part is that even if PAM clearly respond "user unknown", we
got into anyway:

[sybase@server ~]$ isql -Sserver -V
CT-LIBRARY error:
ct_con_props(SET): security service layer: internal security
control layer error: Unable to find SCL entry in configuration file.
1>
and we was in with "sa" identity!

this happened only in interactive mode: if we put the isql command in
a batch file, we found only the above error message in the output file
and no query was executed.
But in interactive, it worked even with unprivilege or remote user,
even with windows clients.
Of course now we have removed the "ase" service from pam.d
configuration, and this does not happen anymore:

[sybase@server ~]$ isql -Sserver -V
CT-LIBRARY error:
ct_con_props(SET): security service layer: internal security
control layer error: Unable to find SCL entry in configuration file.
Msg 4002, Level 14, State 1:
Server 'ASE15LINUXb':
Login failed.
CT-LIBRARY error:
ct_connect(): protocol specific layer: external error: The
attempt to connect to the server failed.

although the server still tries to authenticate with pam, as we seen
from the log:

Apr 24 16:28:11 itflosyb0099 dataserver: pam_unix(ase:auth): bad
username []

but I think this is normal since we have "ANY" authentication model in
our ASE config.

Now I guess we will revert to normal Sybase authentication...

Thank you all guys, it's been great to find your support, since there
are not much resources about sybase on linux on the internet. We sure
will be back soon with more issues ;^)

Bye,
Fabrizio

[Hermooz]

On Apr 24, 3:44 pm, "mpepp...@peppler.org" <michael.pepp...@gmail.com>
wrote:

> The best technique that I've found is to have a file that has the
> password, that is owned by the user running the scripts (probably the
> "sybase" account), and setting the access rights to the file to 0400
> so that it is only readable by the user and root.

I'm inclined to confirm that this is the "least evil" of all possible
solutions.

Bye!
Fabrizio

[Thomas Gagne]

mpep...@peppler.org wrote:
> On Apr 24, 3:31 pm, Thomas Gagne <tga...@wide-open-west.com> wrote:
>
>> The 'is' program has a -C command-line option that tells it to use
>> environment variables for the username/password/server settings. The
>> documentation explains it like this:
>>
>> -C Examine the environment variable HTTP_COOKIE. Modifies the
>> meaning of -U, -P and -S. If -C is supplied, the arguments
>> to -U, -P, and -S can be the names of other environment
>> variables to use for username, password, and server.
>>
>> So if you have another secure way of setting environment variables you
>> could do something lik:
>>
>> setenv HTTP_COOKIE
>> setenv SNEAKYNAME sa
>> setenv SNEAKYPASS mySecretPassword
>>
>> Then the command line would look like: 'is -C -USNEAKYNAME -PSNEAKYPASS'
>>
>>
>
> This is certainly useful for certain situations, but the ps command
> lets you list the env. variables of a process, so the password *could*
> be discovered by a user with even relatively minimal rights on the
> system.
>

Hmm. I just 'man'ed my ps and didn't see where I could list environment
variables. I'm familiar with seeing command-line argument but not
environment variables.

> The best technique that I've found is to have a file that has the
> password, that is owned by the user running the scripts (probably the
> "sybase" account), and setting the access rights to the file to 0400
> so that it is only readable by the user and root. It's still not
> perfect, though.
>

We use a script called ldld that looks for a ~/.dbpasswd file, owned by
the user, that specifies a password to use with each server name.

[Bret Halford]

Thomas Gagne wrote:

>
> Hmm. I just 'man'ed my ps and didn't see where I could list environment
> variables. I'm familiar with seeing command-line argument but not
> environment variables.

Here are a couple of pointers:

http://securitytracker.com/alerts/2007/Feb/1017592.html

http://www.frsirt.com/english/advisories/2006/1123

[Sebastian Willing]

Another solution:

Let your script write a job-cache file (or "public" table).

Add a cronjob which reads the "jobs" from the cache and processes them.
Don't use shell- or SQL-commands in the cache file, just an internal
command code and the required parameters for this command.
The cronjob could be read-only by root and you could supply a password to
isql without security problems.

Sebastian

> Bye!
> Fabrizio
>
>