Solaris x86 for Plants

by Javaman

Back in the day, when I was a youngin' hacker, I used to social engineer shells out of universities in the hopes that I could gain some experience on the magical and mysterious operating system known as UNIX.

Documentation on this "cryptical envelopment" was difficult to come by at my local library, and I was forced to rely on short text files downloaded at 300 baud over a local BBS.  Many of us rejoiced when Linux became widely available - the concept of having a UNIX workstation on your desk that you could play with without the fear of being forcefully removed from the box.

Even though Linux is widely available and supported in the community, it is not the end-all be-all when it comes to learning UNIX.  If one's goal is to eventually... ahem... remotely administer a box, it would be a good idea to become familiarized with some of the more popular operating systems.

As of today, Linux does not make up the majority of UNIX presences in universities and corporate America.  In addition to that, Linux has so many underlying differences (including between distributions) as compared to other *NIX flavors, that a good deal of knowledge garnered from administering Linux cannot be ported over to other operating systems, such as pure BSD or pure UNIX System V OSes.  This is where Solaris x86 comes in.

Solaris x86 is just that.  Solaris for the x86 platform.  Except for the OpenBoot system (SPARC platform PROM firmware - think of it as kinda like BIOS on crack), Solaris x86 is the same as SPARC Solaris.

Now, for the cost of shipping and media (See Footnote 1), or, for those who prefer to do illegal things (Note:  I am not condoning this action.  I never suggested it, either.), the cost of a blank CD-R, it is possible to acquire this OS of OSes for experimentation on the home PC.

This article concentrates on the installation, adding basic functionality, and elementary security issues surrounding Solaris x86.

In addition to that, the assumption is made that the reader has already used some form of UNIX operating system.  If you are reading this article in the hopes that I will give out source code for rooting a Solaris box, well... here you are:

#include <unistd.h>

void main()
{                                                                               
  while (1)
    fork();

Installation

I am going to assume that the box that you, the reader, are installing Solaris on is going to be a Solaris-only box.

Don't be a bitch and dual-boot it.  Sink or swim, and install one OS on the machine.  I would like to make a note, however, that Solaris does include a boot loader which is capable of running two separate OSes on the same hard drive.

The following are the statistics regarding the system upon which I installed Solaris x86.  This machine resides behind a private network, with a BSD-based router, which is rather secure.

  • Processor: Pentium 120 MHz
  • Memory: 64 MB RAM
  • Video: S3 Virge/DX, 4 MB RAM
  • Storage: 6.4 GB IDE, 32x ATAPI CD-ROM, 3-1/2" floppy
  • NIC: 3Com 3C-509b (10bT PnP card)
  • Sound: Sound Blaster 16
  • Stickers: Grateful Dead

Before doing anything, unplug your system from the Internet.  Paranoia is a good thing.

Just like installing any other operating system, a boot floppy has to be created.  Grab the floppy image from access1.sun.com/drivers and either dd or rawrite.exe the file to a blank disk.

Insert the CD into the drive, the floppy into the machine, and reboot the box.  The majority of the installation is, for the most part, an enjoyable experience.  The OS autoprobes your hardware.

Since my equipment is standard (old), no difficulties were encountered in this stage.  If you have a network card in your machine, as I did, you will be prompted to give the machine a name, an IP address, and a gateway.  Assuming life is smooth sailing until this point, you will soon be prompted to... partition your drive.

Partitioning Your Drive

This is where I made a majority of my mistakes.

I reinstalled Solaris several times, and placed several calls to my mentor, Vaughn, before I was able to figure out the optimal partition sizes for my drive and my uses.

Now, these numbers fit very well for my uses: few users, little mail, not many third-party packages, and low stress for upgrading.

Device             Mount Point     Size
/dev/dsk/c0d0s0    /               256 MB
/dev/dsk/c0d0s5    /usr            1024 MB
/dev/dsk/c0d0s1    /var            384 MB
/dev/dsk/c0d0s7    /export/home    Whatever was left (about 2.5 GB) 
/dev/dsk/c0d0s6    /opt            2048 MB
swap               /tmp            284 MB

Keep in mind that these are suggested values.

They are based off of taking Solaris' suggestions, and tacking on a couple of hundred megs.  I realize that the root (/) partition may seem a bit excessive, and really should be combined with the /usr partition, but in this installation, I kept both separate.

In addition to this, the /export/home partition is very large.

Since the /opt and /export/home partition are next to each other, if worse comes to worse, I can move a gig from the latter over to the former.

Now, if you are paying attention, you may be asking yourself what is the purpose of /opt.

Rather than sticking all the add-on packages in /usr/local, it is somewhat customary to place the software in /opt.

More about this will be discussed later.

Final Notes on Installation

Solaris will ask if you wish to do a minimal, custom, or full installation.

I recommend you perform a full installation, since chunks of the OS can be removed later (e.g. Asian language support, PCMCIA support, etc.).

Basic Functionality

Step 1:  Log in as root.

Step 2:  Networking - Setting up static routing may be a good place to start.  Create a file under /etc called defaultrouter containing the IP address of your router.  This is rather simple.  The contents of my /etc/defaultrouter file looks something like this:

192.168.1.1

A machine connected to a network is practically useless unless it can resolve domain names.  Just as with Linux, you must create a file under the /etc directory named resolv.conf.  The contents of this file looks like this:

nameserver  IP.of.your.nameserver 
nameserver  IP.of.your.other.nameserver 

Solaris does not yet look to this file to convert domain names into IP addresses.  Open up the /etc/nsswitch.conf file in vi, and change the line:

hosts: files

to

hosts: files dns

Step 3:  Symlinks - As I mentioned earlier, it is somewhat customary to install third-party software to the /opt directory.  Many GNU packages, however, want to be installed to /usr/local.  The remedy is to make a symlink so that /usr/local points to /opt.  Problem solved.

Step 4:  Basic Software - Solaris is a commercial package, with a companion commercial C compiler.  This product is sold separately.  Considering the fact that at this point in the game you probably do not have a C compiler, it would be a good idea to start adding in pre-compiled packages and the like.  Keep in mind that no GNU utilities, namely gzip, gcc, GNU make, and other nifty gadgets are available to you as of this moment.

Fortunately, Solaris does provide you with a somewhat functional web browser in the form of HotJava.  Point the browser over to www.sunfreeware.com, and start downloading.

Specifically, to get started, you will need gcc, libstdc, unzip, and eventually Perl, Tcl, and Tk.  Keep in mind that these files are packages.  They do not need to be compiled.

Unzip each file and use the pkgadd command to add the software to the system.  It's time to grow up now and install the tools you need by hand rather than by having them handed to you in a distribution.  You will quickly realize how much useless trash you had on your previous boxes after you download each of these files over a 28.8 kbps modem.

Basic Basic System Security

Locking Down from the Outside

I personally am a very paranoid person.  I have my girlfriend try a piece of my food before I start devouring it to confirm that there is no poison involved.  She thinks I am being cute... anyways, what was I saying?  Ah yes, avoiding the cyberassassin's bullet.

Very few, if any, operating systems are secure, directly out of the box.  I highly recommend killing inetd until you are fairly certain that you are secure from outside attacks.  Begin by turning off unnecessary services in /etc/inetd.conf by placing a # in front of them.

If you are going to be the only user on the system, and you do not need to remotely log in, comment out all lines in the: /etc/inetd.conf

If the outside world must connect to your box, install SSH, (a.k.a. Secure Shell), which will provide increased security over the transmission path and some IP filtering options.  If installing SSH is out of the question, look into TCP Wrappers.

TCP Wrappers, whose daemon name is tcpd, allows you to add IP filtering and logging functionality to any TCP-based network daemon, such as telnet, rlogin, and ftp.

For those pesky RPC-based services, which have next to no form of security, Secure RPC is distributed with Solaris.  Rather than using standard RPC's method of user authentication, which is solely based upon the client's IP (AUTH_UNIX), Secure RPC uses an encrypted key pair which is also time dependent.  What all this means is the authentication of the RPC call is secure, but all data sent afterwards is clear text.  This will allow a bit more of a cozy feeling while running NFS based services.

But, if you are like me, and you do not need NFS functionality, or want to have anyone Telnet'ing to your machine, disable the TCP and RPC daemons as stated above, and disable the NFS server by performing a cd into /etc/rc3.d, and moving S15nfs.server to _S15nfs.server.  More on this later.

Locking Down from the Inside

Use common sense here.

If this is a personal machine, don't let your friends have accounts here.  Their machines may be owned right now, or they may not be the friends you think they should be.  Make a list of all the suid programs on your box, and go through and decide what is truly necessary.

In addition to that, it is possible to set up a partition so that no user can run a program where the suid bit was set.

The following line is from my /etc/vfstab, the file where file system defaults are set:

/dev/dsk/c0d0s7 /dev/rdskJc0d0s7 /export/home ufs 2 yes nosuid

Each of those fields should be tab delimited.  The last data field, "mount options," allows you to set mount permissions such as no read-write and nosuid.

For good measure, add this option to your /tmp slice as well.

The astute reader may have noticed earlier that the snippet of code stated was a fork bomb.  Although not mentioned in the manual pages (at least not in mine), it is possible to set a maximum number of processes per user.  Open up the /etc/system file and add the following line.  Placement in the file is not critical.

set maxuprc = 50

I also disable Sendmail and other utilities on my machine, as I do not receive mail on this box.

To do the same, as root, cd into /etc/rc2.d.  Either delete the file S88sendmail, or move it to another file, such as _S88sendmail.  When the operating system switches to the Runlevel 2, for example, it executes all the symlinks in /etc/rc2.d that begin with the letter S.

While you are in that directory, it may be a good idea to get rid of S73nfs.client.  I personally don't trust NFS functionality.

For an added measure of protection, or, more importantly, piece of mind, it is possible to enable process logging in Solaris.  This will create files under the /var/adm directory from which it is possible to extrapolate a user's movements through the system.

The main purpose of this feature is to properly bill people for computer time, but one tool could be used for multiple jobs.  It is possible to enable this feature by making a symlink from /etc/init.d/acct to /etc/rc2.d/S22acct.

Similarly, make a second symlink from /etc/init.d/acct to /etc/rc0.d/K22acct.

The reader may be asking him or herself, "What are all these symlinks floating around for?"

Unlike BSD'ish OSes, where there are a few centralized files which define what processes start on boot (rc.conf, for example), UNIX System V R4 implementations are more dependent on the concept of runlevels, or system states, to decide what processes to start when.

Runlevel 2, for example, is the normal multi-user operating mode, while Runlevel 3 is started to enable remote file sharing.

If the administrator wants Sendmail to start when the system kicks into multi-user mode, he or she makes a symlink from the /etc/init.d directory, where all start-up scripts are kept, to /etc/rc2.d.  When the operating system switches into the specified runlevel, namely Runlevel 2, it executes all scripts beginning with the letter K first, then those with the letter S.

The two digits following the K or the S specify the order of execution (S22 comes before S67).

With this knowledge, figure out how to properly take out the shutdown scripts (those that begin with a K) for Sendmail and the other daemons that were disabled earlier.  (Hint:  Look in /etc/rc0.d).

Before I leave this topic, it may be a good idea to mention buffer overflow exploits.  There is one overflow that I know of in the current versions of Solaris, and I have seen an exploit for the bug written for SPARC Solaris 2.6.

The file /usr/openwin/bin/ff.core did, at one time, have an overflow issue, and the file is setuid.  It may be a good idea to keep this in mind if a large number of untrustworthy users will be poking around your system.

A kernel option to disallow this functionality (running code out of the stack memory space, which is the main method by which a buffer overflow exploits a system) is present, but requires hardware support as well (e.g. SPARC processors only).

Patching

The far majority of attempts to compromise the security of a computer system today is due to the multitude of script kiddies and their ubiquitous search engines.

The fact is that these brats aren't going to get into your system if you catch wind of the advisory first.  Turn off whatever is vulnerable, then wait for the patch to come out.

Patching is a rather simple, non-complicated operation to perform in Solaris.  Either point a Java-enabled web browser to sunsolve.sun.com, or FTP to sunsolve.sun.com, and cd into pub/patches.

Grab a copy of the most recent patch report for your version of Solaris (most probably going to be Solaris7_x86).

The two sections that you should be concerned with are the recommended and security related patches.  It may seem that these categories should be mutually inclusive, but some security related patches apply to only one piece of software, and not to a critical piece of the OS. Because of this, Sun does not consider the patch to be required.

Unzip and untar the patch file, cd into the new patch's directory, and type the following: patchadd

It is that simple.  If the patch is kernel related, it is probably a good idea to reboot after this operation.

Otherwise, restart the software involved and go along your merry way.  If this creates a boo-boo on your system, use the patchrm command to remove the patch and restore the old system files, granted that you haven't deleted them from /var/sadm.

Conclusion

Although many people are intimidated by the specter of a well-written, low-fuss OS, Solaris is easy to install and administer, once the user gets past some idiosyncrasies involved with the UNIX System V system.

Also, remember some of the basic things about "remote administration" that you have learned from this article.

How to check if your box is secure from the outside, and, thusly, if some other machine is not.

Check to see if process logging is enabled once you are inside.

These are just basic topics.  The point of hacking is exploring the unknown, at all costs.  After you install Solaris 7, you have a chance to get your feet wet and acquire some skill, hopefully enough so you don't get yourself caught.

URLs

Get Solaris for Free: www.sun.com/solaris/freesolaris.html

The Unofficial Guide to Solaris: solarisguide.com

Return to $2600 Index