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:dn3723at_private] Sent: Friday, January 31, 2003 3:13 PM To: 'secprogat_private' Subject: RE: Application to Application authentication models.... -----Original Message----- From: r s [mailto:richard.scottat_private] Sent: Friday, 31 January, 2003 10:11 To: secprogat_private 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 **********************************************************************
This archive was generated by hypermail 2b30 : Sat Feb 01 2003 - 14:09:12 PST