Rants about JASS (Solaris Secu­ri­ty Toolk­it)

Recent­ly I switched to a new client where the Solaris Secu­ri­ty Toolk­it (JASS) is exten­sive­ly used. I am now in the process of updat­ing some things, among them are JET and JASS. As part of this work I reeval­u­ate the local JASS mod­i­fi­ca­tions. Pre­vi­ous­ly a cus­tom JASS pack­age was used, but in case JASS is updat­ed by Ora­cle at some point in time (and an update is real­ly need­ed, see below), this would need some amount of work to find out the dif­fer­ences and to for­ward port them to the new ver­sion. If every­thing is well doc­u­ment­ed, this should not be hard to do, but the per­son doing the work also needs to find the up-to-date docs.

To make it more easy I decid­ed to change this. I now install the offi­cial JASS pack­age via JET togeth­er with the lat­est patch for it, and then let JET copy our mod­i­fi­ca­tions over the installed pack­age. Instead of mod­i­fy­ing exist­ing dri­vers, I cre­at­ed our own dri­vers with a ref­er­ence to the dri­ver which served as a base.

While doing this I encoun­tered sev­er­al short­com­ings of JASS on Solaris 10.

There are sev­er­al FS based checks which do not make sense to do for the FS of zones in a glob­al zone (at least not the way I use JASS, so maybe a con­fig­urable way of chang­ing the behav­ior should serve for every­one). If zones are installed in /zones, you do not need to check for files with­out valid UIDs (you sure­ly find a lot of files, as the users are defined inside the zones and not in the glob­al zone) or sim­i­lar things (even not for world writable files, as the zones are installed in a root-access-only sub­tree and inside the zones there may be oth­er secu­ri­ty con­straints con­fig­ured inside JASS, read: it is the respon­si­bil­i­ty of JASS inside the zone to do this). An easy solu­tion would be to exclude those FS which con­tain zones (and as we only have one sub­tree, I just hard­cod­ed this in sev­er­al scripts).

I also miss the pos­si­bil­i­ty (maybe I over­looked a sim­ple way) for the ssh check to lim­it the Allow­Root­Lo­gin to spe­cif­ic hosts. JASS only checks yes or no, but can not lim­it it to spe­cif­ic hosts (e.g. via “Match IP/hostname”). Often you do not need to per­mit root-logins (RBAC/sudo/…), but some­times it is the only way to han­dle a par­tic­u­lar edge-case (or to speed up an action dra­mat­i­cal­ly), and in such cas­es you do not want to allow root-logins more than nec­es­sary.

Send to Kin­dle

Com­pil­ing Sam­ba 3.5.8 with AD sup­port on Solaris 10 u8

If some­one needs a sam­ba which is able to com­mu­ni­cate with an AD 2008 serv­er on a Solaris 10 sys­tem… here is how I did it.

Pre­req­ui­sites

  • /opt/SUNWspro con­tains the Stu­dio 12 com­pil­er
  • tar­balls of openldap-sta­ble-20100719 (2.4.23), heimdal‑1.4, samba‑3.5.8
  • export PATH=/opt/SUNWspro/bin:/usr/xpg6/bin:/usr/xpg4/bin:/usr/perl5/bin:/usr/bin:/usr/openwin/bin:/bin:/usr/sfw/bin:/usr/sfw/sbin:/sbin:/usr/sbin:/usr/sadm/admin/bin:/usr/sadm/bin:/usr/java/jre/bin:/usr/ccs/bin:/usr/ucb CC=cc CXX=CC
  • DEST=/path/to/final/location

Com­pil­ing every­thing

openldap-stable-20100719 (2.4.23)

export CPPFLAGS=”-I/usr/sfw/include” LDFLAGS=”-L/usr/sfw/lib ‑R/usr/sfw/lib”
./configure –pre­fix=$DEST/openldap‑2.4.23 –disable-slapd
make depend
make install

heimdal‑1.4

./configure –prefix=$DEST/heimdal‑1.4 –with-openldap=$DEST/openldap‑2.4.23 –with-hdbdir=$DEST/heimdal-instance/var/heimdal –sysconfdir=$DEST/heimdal-instance/etc
cd lib/hcrypto/libtommath

Unfor­tu­nate­ly heimdal‑1.4 does not con­tain all the files you need. As of this writ­ing (if you try to do this a lot lat­er, you may get more recent ver­sions which may or may not work with heim­dal 1.4) I was able to down­load them from

cd ../../..
make
make install
mkdir ‑p $DEST/heimdal-instance/var/heimdal $DEST/heimdal-instance/etc

samba‑3.5.8

export CPPFLAGS=”-I$DEST/openldap‑2.4.23/include” LDFLAGS=”-L$DEST/openldap‑2.4.23/lib ‑R$DEST/openldap‑2.4.23/lib ‑R$DEST/samba‑3.5.8/lib ‑R$DEST/heimdal‑1.4/lib”
./configure –prefix=$DEST/samba‑3.5.8 –sysconfdir=$DEST/samba-instance/etc –localstatedir=$DEST/samba-instance/var –with-privatedir=$DEST/samba-instance/private –with-lockdir=$DEST/samba-instance/var/locks –with-statedir=$DEST/samba-instance/var/locks –with-cachedir=$DEST/samba-instance/var/locks –with-piddir=$DEST/samba-instance/var/locks –with-ncalrpcdir=$DEST/samba-instance/var/ncalrpc –with-configdir=$DEST/samba-instance/con­fig –with-ldap –with-krb5=$DEST/heimdal‑1.4 –with-ads –with-quotas –with-aio-support –with-shared-modules=vfs_zfsacl
gmake
gmake install

After that you have a sam­ba in $DEST/samba‑3.5.8, the con­fig for it should be put into $DEST/samba-instance/config and if you need to have a cus­tom krb4.conf you can put it int $DEST/heimdal-instance/etc/.

Send to Kin­dle

HOWTO: cre­at­ing your own updat­ed lin­ux RPM for the FreeB­SD lin­ux­u­la­tor

Back­ground info

The FreeB­SD lin­ux com­pat­i­bil­i­ty envi­ron­ment cur­rent­ly uses RPMs from Fedo­ra 10. Unfor­tu­nate­ly Fedo­ra 10 is end of life since a while. For one of the RPMs (the pan­go one) we where aware of a secu­ri­ty vul­ner­a­bil­i­ty. As we do not know if it is fea­si­ble to update the lin­ux­u­la­tor ports to some­thing more recent, I decid­ed to set­up a VM with Fedo­ra 10 and gen­er­ate a new RPM for the linux-f10-pango port. Thanks to Luchesar V. ILIEV for explain­ing me how to do this.

Set­up of the VM

I used Vir­tu­al­Box 4.0.4 on a Solaris 10 x86 machine. I con­fig­ured a fixed size disk of 16 GB and kept the default net­work set­up (after installing the guest tools / ker­nel mod­ules I switched to vir­tio, as I was not able to do any­thing use­ful besides a ping) and RAM size. The CD/DVD dri­ve was con­fig­ured to use the image of the full Fedo­ra 10 DVD for i386 sys­tems.

Set­up of Fedo­ra 10

Boot­ing the VM from the DVD leads to the graph­i­cal Fedo­ra 10 install soft­ware (after chos­ing to install a new sys­tem on the con­sole). There I accept­ed all the defaults, except for the soft­ware to install. I des­e­lect­ed the Office and Pro­duc­tiv­i­ty group and select­ed the Soft­ware Devel­op­ment group. When I was asked if I want to install some addi­tion­al RPMs I had a look at the com­plete list and installed some I thought are nec­es­sary. I do not remem­ber any­more which ones I chose, but every­thing which looks relat­ed to RPM build­ing is a good can­di­date.

After a while the install will be fin­ished and you can boot into the new sys­tem (eject the DVD from the dri­ve before reboot). After reboot chose to install the Guest Addi­tions in the menu of the VM. This should mount the ISO image in the VM. As root exe­cute the file for Lin­ux. This will build some ker­nel mod­ules for bet­ter inte­gra­tion (e.g. seam­less inte­gra­tion of the mouse between your desk­top and the VM). At this point I reboot­ed and con­fig­ured vir­tio as the NIC. I also had to con­fig­ure the net­work set­tings by hand, as the GUI tool did not safe all the set­tings cor­rect­ly.

Update and install of required RPMs

After the VM was up and the net­work con­fig­ured, I updat­ed the entire sys­tem (chose Sys­tem Update in the menu). To update the pan­go port, I had to install the libthai-devel RPM. I had the RPM for it (and all the files I need to build a new pan­go RPM) already down­loaded, so I did a “yum install /path/to/rpm”. At this point I was ready to cre­ate the RPM build envi­ron­ment.

The RPM build envi­ron­ment

As a nor­mal user I exe­cut­ed the com­mand rpmdev-setuptree which cre­ates the direc­to­ry rpm­build and pop­u­lates it with some direc­to­ries. Now you just need to find a suit­able .spec file and put it into rpmbuild/SPECS, put the sources (and maybe patch­es ref­er­enced in the .spec file) into rpmbuild/SOURCES, and you are ready to go (I patched pango.spec for a more recent pan­go ver­sion, basi­cal­ly just chang­ing the ver­sion num­bers). If you want to have a cus­tom pack­ager and ven­dor attribute in the RPM, you can add a line for each to ~/.rpmmacros, e.g. %pack­ager your­name­here and %ven­dor what­ev­eris­ap­pro­pri­ate. I used my @FreeBSD.org EMail address as the pack­ager, and FreeB­SD as the ven­dor.

Build­ing a RPM

I used rpm­build ‑ba –tar­get i386-redhat-linux-gnu –clean rpmbuild/SPECS/pango.spec to build the new pan­go RPM. If every­thing is OK, the result­ing RPMs (a source RPM, a dev­el RPM, a debug­in­fo RPM and the RPM for the bina­ries) are in rpmbuild/RPMS and rpmbuild/SRPMS. For a FreeB­SD port we just need the source RPM (to com­ply to the (L)GPL) and the RPM for the bina­ries.

Addi­tion­al info

The i386-redhat-linux-gnu string which is used for the –tar­get option of the rpm­build com­mand is what seems to be used to build the Fedo­ra 10 RPMs. After build­ing pan­go, the RPM has i686-pc-linux-gnu in some file­names instead (the default val­ue for this set­up). The bina­ries seem to be com­piled for i386, so there should be no prob­lem even for old sys­tems.

Send to Kin­dle

OCP: Ora­cle Solaris 10 Sys­tem Admin­is­tra­tor

After work­ing a long time with Solaris (I start­ed with 2.5.1 at about the time when Solaris 7 was released in 1998), my cur­rent boss decid­ed that it is time that I do a cer­ti­fi­ca­tion for it (clients like it). Two exams lat­er I have it now:

Oracle Certified Professional, Oracle Solaris 10 System Administrator

Since yes­ter­day I am offi­cial­ly an Ora­cle Cer­ti­fied Pro­fes­sion­al, Ora­cle Solaris 10 Sys­tem Admin­is­tra­tor.

The exam ques­tions where a bit strange. I asked myself if a real admin was proof read­ing them or not, but most prob­a­bly some­one with­out much knowl­edge about Solaris admin­is­tra­tion just took the study guides and tried to make some ques­tions out of it.

Any­way, my boss should be hap­py now, and I have some­thing to add to my CV.

Send to Kin­dle

Solaris 10 update 9: the not so nice things about it

I updat­ed some work­sta­tions of the client to Solaris 10 update 9. Upon installing my xorg.conf (dual-screen set­up) I had to notice that it does not work any­more. The prob­lem is, that the NVidia dri­ver does not con­tain sup­port for the graph­ic card we use.

Nor­mal­ly this is not a big deal, this can hap­pen… but in this case this is about SUN Ultra 20 work­sta­tions with SUN pro­vid­ed NVidia Quat­tro FX (NV37GL) cards. Ok, they are not the most recent ones, they where bought 4 – 5 years ago, but still, they just work as need­ed here and the cur­rent Solaris release has no out-of-the-box sup­port for them. I would expect this to work already in a fresh install (yes, I was not able to get the nv dri­ver to work with two screens on this graph­ic card, it seems the nv dri­ver has not sup­port for this).

Solu­tion for me: down­load the old dri­ver from NVidia and inte­grate it into Jump­start (but still, some hours are lost because of first try­ing to get a work­ing dual-screen set­up with the nv dri­ver before tak­ing an old NVidia dri­ver and using it like before in xorg.conf).

Anoth­er glitch a co-worker dis­cov­ered is that StarOf­fice is not includ­ed any­more. That is again some­thing which will cause some loss of time. I will have to have a look how to han­dle it. Prob­a­bly it is best to install it on the serv­er and mount it via NFS on the work­sta­tions. I will see soon if this is can be done (instal­la­tion of OO into a spe­cif­ic place which can be shared) or not.

Send to Kin­dle