RE: Application to Application authentication models....

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Fri, 31 Jan 2003 16:32:16 -0500
From: <Glenn_Everhart@bankone.com>
To: <dn3723@sbc.com>, <secprog@securityfocus.com>

On a given OS, an application may be known to be something based on
its location in the filesystem, on crypto checksums that can be done
by the OS when the app opens, and anything else that may be thought
to be needed. Given an appropriate kernel, it can insist on a crypto
checksum of the memory of the app, and block all non-kernel access to
the checksums. This kind of thing can be fairly difficult to break,
provided that the OS is not otherwise riddled with holes. Again, if all
system objects have ACLs, including the pipes/mailboxes/etc. used by
the app you want to have talk, these might well insist that only
other apps that are believed by the OS to be the ones permitted would
be able to use said pipes/mailboxes/etc.

You want for this that the act of running an application causes some
validity checks to be performed and ensures the identity of the
process running the application gains some attribute (ideally
from the OS, not requiring the app to be specially coded; the VMS
subsystem identifier attribute handling would be an example of part
of such a feature). Then you want to ensure that any communications
channels used by the target process are ACL'd so that only a process
with the application-running identity piece may use them.

A model like this, instead of one that explicitly passes authentication
information, is also possible. If someone gains control of a box
running like this, he can subvert what he pleases. Still, it can be
difficult to do this, particularly where the system takes care to protect
its own control data as well as the applications. Also it may be that
meddled-with lists of what may communicate with what, however they are
encoded, may be easier to notice than the fact that some rogue application,
somewhere in your terabytes of disk, may have a copy of some
password to another app that it should not.

These kinds of controls can be added ahead of "open" operations, on the
whole, and if built right can be pretty strong.

Glenn Everhart

-----Original Message-----
From: NESTING, DAVID M (SBCSI) [mailto:dn3723@sbc.com]
Sent: Friday, January 31, 2003 3:13 PM
To: 'secprog@securityfocus.com'
Subject: RE: Application to Application authentication models....

-----Original Message-----
From: r s [mailto:richard.scott@bestbuy.com]
Sent: Friday, 31 January, 2003 10:11
To: secprog@securityfocus.com
Subject: Re: Application to Application authentication models....

> I disagree in part. The very fact that the security credentials have to > be stored on the filesystem to me, means that there are two possible

Either you have to store the real credentials on the server, or you have
to store credentials to obtain the real credentials. Either way, an
attacker,
with sufficient time and resourcefulness, get into and do anything that your
application can do. Once you accept that, adding complexity will
undoubtedly
slow an attacker down (and perhaps stop a less resourceful one), the expense
here
is the added complexity (which impacts efficiency and stability), so it's a
trade-off.

And mainly my point was more towards the case of a public-facing
application,
with no aspects of that application dealing in sensitive information. When
you
do have to worry about sensitive information, you should definitely take
whatever
steps (as above, and as you suggest) to place every kind of speed bump you
can in
the face of an attacker.

But again, once he has control of your server, you have to assume that he
can do
anything and everything that any process running on that server can do.

> I accept that this may be the case for web applications per machines.
> What if I have two separate applictions running on the same physical box, > one uses very highly sensitive database the other does not. How can I > authenticate the two processes without resorting to basic user id's and > passwords being stored on the filesystem?

Again, you gotta have *something* on the filesystem, or in some way
accessible
to the application, in order for it to remember it when it needs to start
up.
Whether that's an SSL certificate (which could still work on connections
to/from
the same system; the application would just need to validate using more
information), a username and password, or some other key.

> The use of SSL on database connections is considerably high. I am not so
Yah, it is, but in some configurations still very necessary. Your
configuration
may not warrant it.

> The problem is, the application needs to authenticate to the directory
> service. Using certs just binds all applications, potentially, at teh
> physical machine layer, not at the application layer. And accordingly, we

> are left with storing passphrases on the file system.
>
> Any other comments would be great?

Yah, understood. I'm not aware of any industry standard mechanisms to do
what
you're describing. In my experience, each "tier" would just come
pre-configured
(on the filesystem) with the credentials it needs to access non-sensitive
data.
This would generally be independent of the code, so you would deploy from
one
tier to the next, and each application would utilize the centralized
credentials.
Access to sensitive data would be done either via SSL certificates to a
back-end
content system, or in some cases, just proxying SSL credentials from the
user
agent back. All of these credentials would be stored on the local
filesystem,
with proper permissions to restrict access to the user the applications run
as.

I personally don't see much value in storing the credentials elsewhere,
since
this just requires credentials to obtain the credentials be stored on the
filesystem as well. It's just a small speed bump.

I would certainly be intersted in hearing comments from others, though.
This is
certainly an issue that most of us have to deal with. I'm curious to know
how
others approach this as well.

David

**********************************************************************
This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you
**********************************************************************

• Next message: Artem Frolov: "ROI for secure software engineering"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]