Solaris LDAP Insecurities

I've been doing quite a bit of research regarding the native LDAP client bundled with Solaris 9 and 10 and I think I've found a couple of issues.

1. When using "passwd" to change an SSHA hashed password, the resulting password is stored in unix crypt format.
2. Any user on a Sun LDAP client can get a list of all ldap users in the directory (including their encrypted password)
   

Issue #2 is pretty bad to begin with, but coupled with issue #1, it's horrible. You might as well keep everything in /etc/passwd.

After poking around the directory server access logs and ACIs, here's what's going on. The Solaris native LDAP client is binding to the LDAP directory with the proxy user information defined in /var/ldap/ldap_client_cred. As part of the proxy user creation (in idsconfig, I'm assuming) an ACI is created that allows the proxy server to read passwords. When you run ldaplist -l passwd, the LDAP client connects to the directory as the proxy user and does a search for uid=* in ou=people,dc=example,dc=com attributes=ALL. Since the proxy user can read passwords, the encrypted password field is returned by this search and displayed to the user.

The big problem here is that any user on the system can run ldaplist. Also, this returns every user in the directory, not just the users in the netgroups that system is a member of.

For now I've removed the ACI that allows the proxy user to read passwords. This resolves the immediate problem, but may have broken other things. I'm still able to login, change my password, and RBAC seems to be working still.

We'll see how things go over the next couple of days, I guess. :-)

The problem with Open source software..

I was doing my daily news tour (ISC, digg, slashdot, etc) when I came across this.

Apparently, the 0fficial download site for mysql binaries and source packages is gone. Instead of the typical open source MySQL, mysql.com is pushing a new database server called "MySQL Enterprise".

It looks like MySQL is doing the same thing that Red Hat did a few years back. Pulling support for their "Free" version and offering an "Enterprise" product in it's place. While I don't have a problem with this in theory, it does cause a pretty significant problem for people who rely on MySQL for their production databases. At the moment, you can still download the current MySQL binary and source packages from the MySQL community site. However, I believe this will soon change.

This is the basic problem with OSS. It's free - That means you're not going to make much money by selling it. It doesn't make for a very good business plan.

What scares me, though, is how easily companies adopt open source products. I know of at least one mid sized ISP that runs their entire email system on a MySQL database. If the MySQL were to disappear or the license were to change, they would be up a creek big time.

Before implementing any OSS into your environment, you should ask yourself a couple of basic risk management questions.

1. If this project goes stale, can my organization support this product internally?
   
2. Can the license change? If so, how will it impact my organization?

It is up to you and your organization to decide if this is an acceptable risk or not.

Personally, I think that this is a good change for MySQL AB as a company and MySQL as a database. In the end we should see a higher quality product. However, I think the existing MySQL user base is being left out in the cold.

- Mike

UPDATE:

Here are some links..

http://www.mysql.com/news-and-events/news/article_1171.html - official announcement
http://www.planetmysql.org/kaj/?p=64 - planetmysql blog post

UPDATE 2:

It turns out that the links on the community download site are to OLD releases. To get the most current MySQL source release (no binaries available) go to ftp://ftp.mysql.com/pub/mysql/src

Solaris 10, LDAP, RBAC

I've been trying to get Solaris' role based accounting to work via LDAP for the past couple of days. After a call to sun (more on this later), two late nights, and many google queries I've finally got everything working.

Let me start out by explaining what my goal was. I a secure centralized authorization and authentication environment. I want to make changes in one place and only one place. This centralized authentication store needs to support Solaris clients, Linux clients, and applications.

Simple, right?

As it turns out, it is. It took about an hour to get Sun ONE directory server up and running and authenticating unix users. It took about another hour to setup SSL and figure out how to use certutil to create the cert8.db and key3.db files that Solaris clients use to verify the LDAP server's certificate is valid. This took care of authenticating Solaris and Linux boxes.

One problem with keeping all of your users in a single repository is that, well, all of your users are in a single repository. Every user is on every box. Insanity. Fortunately, there are these things called netgroups. Netgroups are a throwback from the old NIS days and allow you to assign users to groups, and then assign groups to servers.

The next thing on my on my list was Solaris' Role Based Accounting (RBAC). RBAC is pretty stright forward. You assign commands to profiles, profiles to roles, and roles to users. Most of the administrative profiles and commands are preconfigured in Solaris, so all you really need to do is create a role with the access profiles you want and assign it to a user. I hadn't done this before, so I spent a little bit of time getting comfortable with it. Once I was pretty comfortable with it, I decided to load it into the LDAP directory. This is where I first ran into problems.

First off, if you're running Solaris 8 or 9 - good luck. There are several older documents floating around the internet that describe how to do this using an ancient tool called dsimport. Dsimport hasn't been updated since Directory Server 4.0 and doesn't work at all. The script is still bundled with the Directory Server, but the Java classes it calls are not. It took me a bit to figure this out.

Dsimport was replaced by a tool called 'ldapaddent' that ships with Solaris 8 and above. The problem is that the version of ldapaddent that ships with Solaris 8 and 9 is unable to import the RBAC databases. No dsimport and no ldapaddent. I still don't know how you're supposed to load this data into the directory on those systems.

Luckily for me, the Solaris 10 ldapaddent does support these files and can import them into LDAP. Once I got my data into the directory, I changed nsswitch.conf and much to my delight, I saw my roles and profiles when I ran "roles" and "profiles". The only problem is that although I could see the roles and profiles assigned to me, I couldn't actually use them. This is where things got sticky.

After banging my head into the wall for about 4 hours, I decided to give in and call Sun for support. The Directory Server rep I was speaking to didn't even know how to setup LDAP over SSL, let alone troubleshoot my problem. While I was on hold, I finally figured out the problem. When you login, your profile shell (pfksh) queries LDAP for your roles and profiles. Since the profile shell is running as your user, cert8.db and key3.db need to be readable. This fixed RBAC over ldap on Solaris 9 clients, but for some reason Solaris 10 clients still weren't working.

Just for kicks I tried using my unencrypted ldap profile to see if there was any difference. While using an unencrypted SSL session, everything worked. Exact same settings, exact same directory. The only difference was SSL vs. plain text. Since I just fixed the permissions on the certificate files, that couldn't be the problem. Another thing I noticed is that while I could run ldaplist as root, when I tried to do it under my normal userid it failed. I trussed ldaplist as root and then again as my user. The difference was that the root ldaplist was fopening /var/ldap/cert8.db and /var/ldap/key3.db and the unprivileged user was not. Turning on debug logging confirmed my fears, LDAP queries as my user were failing because they could not verify the certificate from the server.

After a couple more hours, I found a sunmanagers message with a similar problem. The answer? The default runtime linking environment in Solaris 10 isn't setup. For some reason, Solaris thought it would be cool to load some weird broken LDAP libraries for me instead of the ones that actually work. I ran these commands and everything worked perfectly.

[root@sol10client /]# crle -u -s /usr/lib/mps
[root@sol10client /]# crle -64 -u -s /usr/lib/mps/64

To make a long story short. RBAC in LDAP isn't very well documented. Use ldapaddent on a Solaris 10 box to populate the data in the LDAP directory. Since RBAC queries LDAP under your UID, you need to make sure that your UID can read the certificate files in /var/ldap. If your client is Solaris 10, you need to configure the runtime linking environment with the commands above.

Hopefully this saves you some gray hairs.

- Mike