Don't authenitcate the application to the database. Authenticate the user to the database. The user supplies a credential (password, certificate, biometric, etc), and the application, acting on the user's behalf, forwards the credential to the database. The database consumes the credential, performs authorization, and delivers data to the user, again through the application.
Kerberos provides a great mechanism for this. Using pkinit, you can use various credential types. Or, stick to the basics and use passwords. Most databases support GSSAPI (or SSPI) now, and using GSSAPI in your app shouldn't be too difficult.
So, the user supplies credentials on demand, nothing is embedded in source, binary, or external configs.
If Redhat is like "dating, where you have to offer your date value in order to entice them". then isn't Microsoft like prostition, where you pay up front, don't know what you'll get till you open the package, and never know what kind of virus you could walk away with?
So, running Vista is sooo much harder/more complex/less efficient/ than previous OSs that *more* people need to be hired?!? And that is a good thing how?
Exactly! Why would a vendor be willing to limit themselves to write code only for Windows, but not willing to limit themselves to a finite number of (or even a single) Linux distribution? The analog to a Windows-only software vendor is a Redhat-only software vendor or a AIX-only software vendor. Redhat is not a shifting environment (at least, no more so than Windows). There is no analog to a "Linux" software vendor in the Microsoft world, as there is no analog to Linux in the Microsoft world (again, the analogy is "*Redhat* Linux" or "*Novell* Linux" to Windows).
Vendors do not generally set a target of "Linux". Vendors set targets like "Supported on Redhat Enterprise 3 and SuSE Enterprise 9", etc, based on a finite number of supported configurations, much like saying "Supported on Windows 2000, Windows 2003 Server, Windows XP Professional, Vista Professional, Vista Ultimate, Vista Home, Vista Media..."
As an aside, I generally avoid statements like "Linux comes in hundreds of different distros...", and refer instead to "Redhat Linux" and "Novell Linux" as completely distinct operating environments, with distinct support, configuration, and software requirements.
The comparison is not Windows vs. Linux. It is Windows vs. Redhat Linux vs. Solaris vs. Novell Linux vs. Debian Linux vs. AIX...
"Windows" is not comparable to "Linux" !!! One does not run "Linux" (generally), one runs "Redhat Linux", or "SuSE Linux", or "Debian Linux".
Therefore, it is necessary to compare the complexity of Windows with the complexity of a single Linux distro. If your Microsoft-friendly organization would be willing to consolidate on Windows, then your analogous Linux-friendly organization would be willing to consolidate on a single Linux distro, avoiding the multi-distro complexity.
If your organization is heterogeneous, and that is your "complexity" concern, then Windows is actually your problem! If you run or write software for multiple Linux distros, AIX, Solaris, HP-UX, and Windows, which one is the odd-ball? Admin'ing *nix systems is all similar, while Windows is *much* different. Porting from one *nix to another is easy, compared to porting *nix to Windows or Windows to nix.
I will grant that MS Windows provides a tighter integration for MS SQL, Exchange, and AD, than (for example) Novel or Redhat Linux provides for the database, groupware, and authN/authZ software included in their repositories. That is the cost of flexibility, which is oft balanced by the savings of flexibility. But this article attempts to pin the cost on the variation of distros, which is not correct.
The comparison is not Windows vs. Linux. It is Windows vs. Redhat Linux vs. Solaris vs. Novell Linux vs. Debian Linux vs. AIX...
While SSL is not intended to prevent spamming, it is meant to prevent spoofing, thereby hindering phishing. SSL is more than just encryption via PKI -- given a proper trust fabric, it can provide proof of identity (via signing), thereby preventing man-in-the-middle attacks (which is the counter-attack to encryption without signing).
If you don't have a proper trust fabric (provided by a commonly trusted CA in the SSL scenario), then all of your encrypted traffic is still vulnerable to a simple MITM attack.
Is this transaction between my system and MS encrypted? I need to be able to determine the contents of this transaction, to prove that no sensitive data (HIPAA/SEVIS/FERPA) is leaving my system.
Or, maybe I can use this to finally convince my management that sensitive information does not belong on a MS system, as we may never know when MS will peruse our data. I do not honestly expect MS to ever actually browse our data, but unless I can prove beyond a shadow of a doubt that these "phone home" transactions do not, and will never, contain data, how can I trust this system? What if MS decides in their infinite wisdom to send debugging info home, and that contains a memory dump including even a single user record, containing name, address, SSN... ?
Gotta love OSS - at least there is a code audit path, should I need to supply proof of behavior.
If you truly do not want to make your code FOSS, then I am a believer in not giving the code out at all, even under contract. Code has a way of making it out to the 'net.
Instead, how about extending your architecture to allow for a plugin & theming framework? Graphical modifications are handled through a theming engine, workflow/process changes are handled through plugins and configuration files.
I understand that this means (potentially) much cost, but it is (potentially) less cost than recovering from a code leak. Think of this "boxed" version as a *new* COTS product for you, as you will be moving from service revenue to product revenue, and then invest R&D and effort into it as such.
Passwords are for "Authentication". Your user has already been authenticated. You are now looking for "Identity Forwarding" or "Identity Session Management". Do not use passwords are your Identity Token. Look at technologies like Kerberos, which use your password for authentication, give you a identity token in the form of a TGT (Ticket Granting Ticket), and then allow you to request unique (and optionally forwardable) tokens for each service you are looking to access.
In the web world, CAS provides proxy tickets, which can even be forwarded (for example, to an FTP server) as a stand-in for passwords via PAM.
Given rich ACLs, there is really very little that needs to be done as root. However, when root is needed, it is important to remember that there is only one root. On a machine with multiple admins, how do you tell who logged in as root? The sudo log entry tells all:
So, at $42.2222 per troy ounce, and 14.5833333 troy ounces in 1 pound, if these sites are really "worth their weight in gold", then on.com weighs ~1/2 ton while jasmin.com weighs only ~1/4 ton. Makes sense, of course, given the starvation diets most of those girls are probably on...
Please don't crucify me if my math is off... I'm tired. Just laugh at attempted joke....
OpenVPN all the way! My server and client config files are each < 10 lines long. I manage my certificates with TinyCA. I think all of this is readily available via apt. Also has Windows and OSX clients.
iCal is a calendaring file standard. Apple just chose to use the same name for their Calendar product (the obsession with "i*"). Gmail is compliant with the iCal standard, which happens to allow Apple's product (which is standard compliant) to interoperate.
Time-constraints are an "authorization" (AuthZ) issue, not an "authentication" (AuthN) issue. Kerberos does its job well because it is focused solely on AuthN. Try to avoid the urge to make it do AuthZ as well.
So, what to do...
If you are looking to limit Windows hosts, you won't be able to use LDAP directly. For central AuthZ of Windows services, you will have to use either AD or NDS, both of which support time-of-day contraints. With AD (not sure about NDS), you can leverage your Kerberos AuthN with a cross-realm "trust", and use AD for the AuthZ (Kerberos princ gets mapped to an AD princ). Perhaps Samba as a fake-PDC could also do this for you?
If you are only looking for Unix hosts, writing a PAM module is not too difficult. Perhaps you could simply modify pam_time to read it's config from LDAP.
"More choices are rarely a bad idea. I dislike bundled crapola that I'll never need or want."
I agree, but I think eight baseline distributions will be a nightmare for them to support, and a nightmare for us to choose and upgrade between. One baseline "Windows Vista" would be sufficient, plus something like apt-get (ms-get media-player) or a nice little entry on the Microsoft Update page to "Install Cable Card Support", or "Install Media Player Support". You could even be guided through a shopping cart type environment, so they could charge for the "upgrades".
Why sell 8 distinct versions? Maybe better answered with another question - if I buy "Windows Home Premium", can I "upgrade" to "Windows Vista Business" for a reduced cost?
What if I have a website for mountain climbers to discuss their American tours? Wouldn't mountain-america.net be a valid name? Shouldn't I be allowed to purchase an SSL certificate to secure logins to my fourms?
I fear the day that commercial entities own the namespace of the internet, all for name recognition and protecting users from themselves. Trademark law worked great for localized commerce, but with global environments (like the internet), how can one guarantee and protect unique naming without outlawing much of the english language?
Oddly enough, I'm at a Identity Management conference in Tempe AZ right now. Although in practice, getting all of your service providers (customers, bank, etc) into a single federation is probabably near impossible, getting them into a smaller number of bridged federations may happen through business needs and market pressure within the next few years. Check out technologies like Shibboleth (http://shibboleth.internet2.edu/) or Liberty Alliance.
"Let it sit for a day on the network". Heh -- I wish! Depending on the phase of the moon, we (large public University network) have seen TTC (time to compromise) as small as 15 minutes for an unpatched system. Those patches have to go on immediately!
Actually, I'm concerned that services (like MS Fax, an AV product, a filesystem indexer) running as SYSTEM may reregister the DLL, and then either the same service or another use it. Once the DLL is registered and loaded, I don't think the Filesystem ACL will do any good. Too bad there are no "in-memory" execution ACLs!
Out of curiousity, as I can't tell from the Linux box I type this at: does Everyone-Deny block "Administrator" ?
Reading the article, the ISC (and a few others) say that you *should* disable the DLL. There are two ways, with caveats, listed: *Unregister the DLL : some apps may actually reregister the DLL. *Rename/Delete: make sure XP File Protection is off, otherwise it will be replaced. Also, some apps may behave badly.
So, disabling the DLL is a *good* idea -- but may not be a complete solution by itself.
Slashdot Mirror
How about "free" + "open" = "frepen"? (FREH-pen)
Have you tried that new frepen software?
That's the best frepen software I've ever used!
That frepen software frepped my freppy frep, and now I'm frepping frepped!
Don't authenitcate the application to the database. Authenticate the user to the database. The user supplies a credential (password, certificate, biometric, etc), and the application, acting on the user's behalf, forwards the credential to the database. The database consumes the credential, performs authorization, and delivers data to the user, again through the application.
Kerberos provides a great mechanism for this. Using pkinit, you can use various credential types. Or, stick to the basics and use passwords. Most databases support GSSAPI (or SSPI) now, and using GSSAPI in your app shouldn't be too difficult.
So, the user supplies credentials on demand, nothing is embedded in source, binary, or external configs.
Link
If Redhat is like "dating, where you have to offer your date value in order to entice them". then isn't Microsoft like prostition, where you pay up front, don't know what you'll get till you open the package, and never know what kind of virus you could walk away with?
So, running Vista is sooo much harder/more complex/less efficient/ than previous OSs that *more* people need to be hired?!? And that is a good thing how?
Exactly! Why would a vendor be willing to limit themselves to write code only for Windows, but not willing to limit themselves to a finite number of (or even a single) Linux distribution? The analog to a Windows-only software vendor is a Redhat-only software vendor or a AIX-only software vendor. Redhat is not a shifting environment (at least, no more so than Windows). There is no analog to a "Linux" software vendor in the Microsoft world, as there is no analog to Linux in the Microsoft world (again, the analogy is "*Redhat* Linux" or "*Novell* Linux" to Windows).
..."
Vendors do not generally set a target of "Linux". Vendors set targets like "Supported on Redhat Enterprise 3 and SuSE Enterprise 9", etc, based on a finite number of supported configurations, much like saying "Supported on Windows 2000, Windows 2003 Server, Windows XP Professional, Vista Professional, Vista Ultimate, Vista Home, Vista Media
As an aside, I generally avoid statements like "Linux comes in hundreds of different distros...", and refer instead to "Redhat Linux" and "Novell Linux" as completely distinct operating environments, with distinct support, configuration, and software requirements.
The comparison is not Windows vs. Linux. It is Windows vs. Redhat Linux vs. Solaris vs. Novell Linux vs. Debian Linux vs. AIX ...
...
"Windows" is not comparable to "Linux" !!! One does not run "Linux" (generally), one runs "Redhat Linux", or "SuSE Linux", or "Debian Linux".
Therefore, it is necessary to compare the complexity of Windows with the complexity of a single Linux distro. If your Microsoft-friendly organization would be willing to consolidate on Windows, then your analogous Linux-friendly organization would be willing to consolidate on a single Linux distro, avoiding the multi-distro complexity.
If your organization is heterogeneous, and that is your "complexity" concern, then Windows is actually your problem! If you run or write software for multiple Linux distros, AIX, Solaris, HP-UX, and Windows, which one is the odd-ball? Admin'ing *nix systems is all similar, while Windows is *much* different. Porting from one *nix to another is easy, compared to porting *nix to Windows or Windows to nix.
I will grant that MS Windows provides a tighter integration for MS SQL, Exchange, and AD, than (for example) Novel or Redhat Linux provides for the database, groupware, and authN/authZ software included in their repositories. That is the cost of flexibility, which is oft balanced by the savings of flexibility. But this article attempts to pin the cost on the variation of distros, which is not correct.
The comparison is not Windows vs. Linux. It is Windows vs. Redhat Linux vs. Solaris vs. Novell Linux vs. Debian Linux vs. AIX
Why does this Japanese group have an English acronym?
While SSL is not intended to prevent spamming, it is meant to prevent spoofing, thereby hindering phishing. SSL is more than just encryption via PKI -- given a proper trust fabric, it can provide proof of identity (via signing), thereby preventing man-in-the-middle attacks (which is the counter-attack to encryption without signing).
If you don't have a proper trust fabric (provided by a commonly trusted CA in the SSL scenario), then all of your encrypted traffic is still vulnerable to a simple MITM attack.
Is this transaction between my system and MS encrypted? I need to be able to determine the contents of this transaction, to prove that no sensitive data (HIPAA/SEVIS/FERPA) is leaving my system.
... ?
Or, maybe I can use this to finally convince my management that sensitive information does not belong on a MS system, as we may never know when MS will peruse our data. I do not honestly expect MS to ever actually browse our data, but unless I can prove beyond a shadow of a doubt that these "phone home" transactions do not, and will never, contain data, how can I trust this system? What if MS decides in their infinite wisdom to send debugging info home, and that contains a memory dump including even a single user record, containing name, address, SSN
Gotta love OSS - at least there is a code audit path, should I need to supply proof of behavior.
If you truly do not want to make your code FOSS, then I am a believer in not giving the code out at all, even under contract. Code has a way of making it out to the 'net.
Instead, how about extending your architecture to allow for a plugin & theming framework? Graphical modifications are handled through a theming engine, workflow/process changes are handled through plugins and configuration files.
I understand that this means (potentially) much cost, but it is (potentially) less cost than recovering from a code leak. Think of this "boxed" version as a *new* COTS product for you, as you will be moving from service revenue to product revenue, and then invest R&D and effort into it as such.
Passwords are for "Authentication". Your user has already been authenticated. You are now looking for "Identity Forwarding" or "Identity Session Management". Do not use passwords are your Identity Token. Look at technologies like Kerberos, which use your password for authentication, give you a identity token in the form of a TGT (Ticket Granting Ticket), and then allow you to request unique (and optionally forwardable) tokens for each service you are looking to access.
In the web world, CAS provides proxy tickets, which can even be forwarded (for example, to an FTP server) as a stand-in for passwords via PAM.
Given rich ACLs, there is really very little that needs to be done as root. However, when root is needed, it is important to remember that there is only one root. On a machine with multiple admins, how do you tell who logged in as root? The sudo log entry tells all:
/var/log/auth.log
Apr 15 22:05:41 linux-black sudo: matt : TTY=pts/0 ; PWD=/home/matt ; USER=root ; COMMAND=/usr/bin/tail
sudo is valuable if only for the logging. Yes, you can limit what can be done using the sudoers file, but logging who did what is invaluable.
So, at $42.2222 per troy ounce, and 14.5833333 troy ounces in 1 pound, if these sites are really "worth their weight in gold", then on.com weighs ~1/2 ton while jasmin.com weighs only ~1/4 ton. Makes sense, of course, given the starvation diets most of those girls are probably on ...
... I'm tired. Just laugh at attempted joke ....
Please don't crucify me if my math is off
OpenVPN all the way! My server and client config files are each < 10 lines long. I manage my certificates with TinyCA. I think all of this is readily available via apt. Also has Windows and OSX clients.
iCal is a calendaring file standard. Apple just chose to use the same name for their Calendar product (the obsession with "i*"). Gmail is compliant with the iCal standard, which happens to allow Apple's product (which is standard compliant) to interoperate.
Time-constraints are an "authorization" (AuthZ) issue, not an "authentication" (AuthN) issue. Kerberos does its job well because it is focused solely on AuthN. Try to avoid the urge to make it do AuthZ as well.
...
So, what to do
If you are looking to limit Windows hosts, you won't be able to use LDAP directly. For central AuthZ of Windows services, you will have to use either AD or NDS, both of which support time-of-day contraints. With AD (not sure about NDS), you can leverage your Kerberos AuthN with a cross-realm "trust", and use AD for the AuthZ (Kerberos princ gets mapped to an AD princ). Perhaps Samba as a fake-PDC could also do this for you?
If you are only looking for Unix hosts, writing a PAM module is not too difficult. Perhaps you could simply modify pam_time to read it's config from LDAP.
"More choices are rarely a bad idea. I dislike bundled crapola that I'll never need or want."
I agree, but I think eight baseline distributions will be a nightmare for them to support, and a nightmare for us to choose and upgrade between. One baseline "Windows Vista" would be sufficient, plus something like apt-get (ms-get media-player) or a nice little entry on the Microsoft Update page to "Install Cable Card Support", or "Install Media Player Support". You could even be guided through a shopping cart type environment, so they could charge for the "upgrades".
Why sell 8 distinct versions? Maybe better answered with another question - if I buy "Windows Home Premium", can I "upgrade" to "Windows Vista Business" for a reduced cost?
What if I have a website for mountain climbers to discuss their American tours? Wouldn't mountain-america.net be a valid name? Shouldn't I be allowed to purchase an SSL certificate to secure logins to my fourms?
I fear the day that commercial entities own the namespace of the internet, all for name recognition and protecting users from themselves. Trademark law worked great for localized commerce, but with global environments (like the internet), how can one guarantee and protect unique naming without outlawing much of the english language?
Oddly enough, I'm at a Identity Management conference in Tempe AZ right now. Although in practice, getting all of your service providers (customers, bank, etc) into a single federation is probabably near impossible, getting them into a smaller number of bridged federations may happen through business needs and market pressure within the next few years. Check out technologies like Shibboleth (http://shibboleth.internet2.edu/) or Liberty Alliance.
"Let it sit for a day on the network". Heh -- I wish! Depending on the phase of the moon, we (large public University network) have seen TTC (time to compromise) as small as 15 minutes for an unpatched system. Those patches have to go on immediately!
I'm more worried about a service reregistering the DLL on startup, then other services or user-space apps using the (now vulnerable) service.
Actually, I'm concerned that services (like MS Fax, an AV product, a filesystem indexer) running as SYSTEM may reregister the DLL, and then either the same service or another use it. Once the DLL is registered and loaded, I don't think the Filesystem ACL will do any good. Too bad there are no "in-memory" execution ACLs!
Out of curiousity, as I can't tell from the Linux box I type this at: does Everyone-Deny block "Administrator" ?
Except SYSTEM may bypass Everyone-Deny ...
Reading the article, the ISC (and a few others) say that you *should* disable the DLL. There are two ways, with caveats, listed:
*Unregister the DLL : some apps may actually reregister the DLL.
*Rename/Delete: make sure XP File Protection is off, otherwise it will be replaced. Also, some apps may behave badly.
So, disabling the DLL is a *good* idea -- but may not be a complete solution by itself.