David Lee Todd, Unknown Product Manager

I had shelved my Solaris-at-home project for several months, waiting to see if Solaris 10, Update 2, would include the agpgart driver that I needed if I wanted to have a video display larger than the tiny one I was stuck with, one more suitable for Computer Programmer Barbie than for a full-sized human being. Alas, when Update 2 came out, the driver was still absent. Alan Coopersmith was kind enough to reply to my inquiry about whether or not the agpgart had made it in, and he also noted that OpenSolaris has contained the agpgart driver for more than a year.

I had been thinking about lifting the driver from OpenSolaris and installing it on my system,. but my Engineering Support buddy Hermelito Go, Unix admin extraordinaire, suggested I just upgrade to OpenSolaris, and his colleague, Fabio Duarte, volunteered to burn me a DVD with a recent Nevada build, Snv_42. Off to the races!

At home, I got my experimental Dell Inspiron 1100 from the shelf where it had lain for months awaiting the agpgart. I booted it up with the old Solaris 10, and was aghast to realize that I had neglected to write down my root password, and could no longer log in. Rats! Oh well. I decided to do a clean install of OpenSolaris, which was probably a better idea anyway, given the weird things I had tried with my first Solaris project.

The install was uneventful. It actually seemed easier than the last time. The menus looked a little nicer, too. So far, so good. Along the way, I noticed what seems to me to be a huge security hole. The install sequence asks you to choose a root password BEFORE it asks you whether you want to do a new install or an upgrade. This implies that if I steal someone's Solaris machine, all I have to do to gain access to every file on it is to upgrade the OS and name myself root. I hope I'm wrong about this.

When the install was completed, I was horrified to see that I still had the tiny, Barbie-sized display. Grrr. I had to admit, though, that the colors and resolution were better than they were on Solaris 10. Hmm. Clearly something had changed for the better. I decided to see what I could do by running kdmconfig.

Running kdmconfig proved to be very interesting. First, it showed that I was running on the Xorg X-server! Excellent. You may remember that on Solaris 10, I couldn't get Xorg to run at all, due to the lack of the agpgart, and that switching to Xsun allowed me to run, but only with the Barbie-sized display. Since Xsun had been more successful the first time, I decided to try it again, and switched in kdmconfig.

Then, as usual, I snatched defeat from the jaws of victory. I couldn't log in. Every time I entered my username and password in the login screen, the screen disappeared, then reappeared and asked me to log in again. This was weird, because I could log in under Xorg. Even weirder, a few minutes of experimentation showed that it was actually the Gnome desktop that I couldn't log in to under Xsun, but that I could log in to the Common Desktop Environment (CDE), as well as the command line and a fail-safe session. Also, the CDE seemed to be missing certain applications, like StarOffice.

So, what to do? I'm thinking I'll just sit tight until the OpenSolaris guys get around to fixing the problem with the login. They've done a nice job getting the agpgart to run, so I'm sure they'll get the login squared away.

Comments:

You Wrote:
This implies that if I steal someone's Solaris machine, all I have to do to gain access to every file on it is to upgrade the OS and name myself root. I hope I'm wrong about this.

My Comment:
Easier than an upgrade would be to just boot in single user off an install disk or netboot the same image.

That is the recognized way to recover lost root passwords.

This doesn't work for a single user boot from the disk as you are prompted for the current root password to enter single user mode.

Until zfs has crypto support or encrypted lofi is available, you could set a bios password. Or create your own loopback file based fs. Of course if the file is decrypted and the attacker steals your laptop you are out of luck. So only having the decrypted data in /tmp would offer some protection.

I discuss a quick and dirty encrypted file lofs idea in my blog as it seems to be a bit much for a comment.

Or another way: If the attacker has physical access all bets are off until fs level encryption is available.

Posted by Yakshaving on September 10, 2006 at 09:30 AM PDT #

Or another way: If the attacker has physical access all bets are off until fs level encryption is available.

its worse than you think thanks to ZFS all you have to do is, steal the harddrive, connect to a new solaris box, doesn't matter if its the same arcutecture. Sparc or x86 is meaningless. Just connect the device, and enter two commands. zpool import , get the poolname, and then zpool import -f poolname, all the files are yours. No researching how pools are layed out, overriding metadb's just two simple commands. No guessing what slice has the root filesystem on it.

Posted by James Dickens on September 10, 2006 at 08:05 PM PDT #



	David Lee Todd, Unknown Product Manager People who love sausages and software should never watch either being made