Blogosphere news from you friendly OSS dude.

PCA: The future of Solaris patching ??

Here is another post about patching Sun Solaris systems.

Even though I personally think that the features provided by smpatch(1M) are an improvement compared to the previous patch utilities like patchdiag, patchcheck and patchpro there's always room for improvement.
So i started snooping around to find a utility called PCA which stands for Patch Check Advanced.
PCA is only 2 files, a small perl script (around 1500 lines of code) and a manpage.
Here's a quote from the pca author's website to give you an impression about pca's design:

"A lot of care is taken to guarantee that pca doesn't omit patches which might apply to a system. This is the most important design principle. I'm manually checking that it's fulfilled on a daily basis".

You can run pca without root privileges to see which patches can be applied to your system.
When being run without any arguments, pca produces a nice and clean overview of the required patches (after having analyzed the dependencies) which are applicable for your system and it shows this overview in the correct order of installation.
PCA makes it real easy to list the contents of a patch's README file as well which i find to be tremendously usefull.

I could sum up all the options pca is currently offering but a link to the PCA website is much more appropriate :)

I've been using pca for about a week now so i'm aware that's not a really long time but what i've seen so far, i'm already impressed by pca's capabilities.

posted by Marco @ 13:06 0 comments

Enabling the Solaris 10 IP packet filter (IP Filter) HowTo

Okay, here a little post to stay on the security topic :)

How does one enable the supplied packet filter within the Solaris 10 OS to secure ones system?

Note: in my case, i already setup the actual filtering policy by populating /etc/ipf/ipf.conf.

Well here we go:

You start by reading either ipf(1M) or ipfilter(5) which clearly states you need to edit /etc/ipf/pfil.ap to include the names of the network interface(s) to be filtered.
My system uses a Broadcom Gigabit Ethernet controller using the bge(7D) driver.
So uncomment the bge line in the pfil.ap file and write the change to that file.

Then you need to configure the network interface so it makes use of the network/pfil service.
You can accomplish this by rebooting the system (this clearly is the easiest way).
Once you've rebooted your system you can verify via ifconfig(1M) if the pfil module has been inserted to the ethernet controller.

# ifconfig bge0 modlist
0 arp
1 ip
2 pfil
3 bge

So you can see that the pfil module has been successfully inserted at position 2.

After the reboot you only have to enable the network/ipfilter service instance via svcadm(1M) to end up with a working packet filter.
For those who wonder why you only need to enable the network/ipfilter service instance and not also the network/pfil service instance is 'cuz the network/pfil service instance is actually a dependency for the network/ipfilter instance and thus will be enabled automagically thanks to the great smf(5) implementation into the Solaris 10 OS !

# svcs -d network/ipfilter
STATE STIME FMRI
online 11:42:34 svc:/network/pfil:default
online 11:42:42 svc:/system/filesystem/usr:default
online 11:42:45 svc:/network/physical:default
online 11:42:46 svc:/system/identity:node

But ipf(1M) clearly states that you can also restart/enable the network/pfil service instance via svcadm(1M) and then enable the network/ipfilter service instance.
Then unplumb and plumb the network interface and manually enable ipf.
That way you don't have to reboot your system.

If you have the Solaris IP Filter up and running you can use ipfstat(1M) to list your active ruleset by issueing the following command(s):

# ipfstat -ihn (dislays the inbound list)
# ipfstat -ohn (displays the outbound list)

As always, please do read the supplied manpages as they are valuable information for getting things working ;)

posted by Marco @ 16:52 0 comments

Changing user-level attributes with Solaris 10 security policy

A colleague at work told me that he changed the CRYPT_DEFAULT in policy.conf(4) on his nevada box to md5 (the Sun implementation of md5).
I actually forgot to change the default unix crypt for generating the password for my user login when i installed my Solaris 10 1/05 system a long time ago so it was about time I changed this myself into something a little more secure wouldn't you say? ;)

The only thing that's required if you want to change the salt via crypt_gensalt(3C) to generate a new crypted password for your account is to change the CRYPT_DEFAULT setting in policy.conf(4) from the default __unix__ value to either:

1 (will use the BSD/Linux md5 algo)
2a (will use the BSD Blowfish algo)
md5 (will use Sun's md5 algo)

My personal favorite has always been the blowfish algo so i'm sticking with it.

Once you've changed the value of the CRYPT_DEFAULT key in /etc/security/policy.conf and have written the file, the only thing left to do is setting a new password on your account via passwd(1) and you're done!

To verify whether the crypt change worked is to take a look at the line in /etc/shadow for your user account and see whether the password column has changed (actually logging into the box again would be a good method too ;) )

w00t, that simple :)

posted by Marco @ 16:21 0 comments

Solaris 10 6/06 and ZFS behavior

I'm running the official Solaris 10 6/06 (aka Update 2) release on an x86 laptop.
This release comes with ZFS version 2 and I decided to try it out a bit.
Having played with ZFS before running on various builds of Solaris Express Community Release (SX:CR for short) i was interested to give ZFS on a Solaris 10 release a spin.
I got to this 6/06 install via an upgrade from the Update 1 release (which didn't come with ZFS) and thus the filesystem with its slices was already laid out.
So i had no more room for a couple of slices to create a ZFS storage pool from (let alone having a second drive).
Well, no biggy 'cuz ZFS also lets you experiment by creating a pool from files (for experimental purposes according to ZFS(1M)).
So I created 2 1 gigabyte files thru mkfile(1M) within my homedirectory handled by the automounter.
Once the files were created, i created a storage pool out of them.

Commands used:
# zpool create zstorage /home/marcovl/zstor1 /home/marcovl/zstor2 (zpool requires absolute pathnames to the location of the files to be used)
# zfs create zstorage/stuff
# zfs set mountpoint=/export/stuff zstorage/stuff

Well, all was well, i got a storage pool of 2 gigs mounted on /zstorage and a zfs filesystem called zstorage/stuff mounted on /export/stuff.

I hadn't run the smpatch utility for a while and there were some patches to be applied so i decided to patch the system.
After the smpatch process was finished i had to reboot the system for some patches to be applied cleanly.

Then came the surprise: my freshly created ZFS storage pool wasn't automounted by default after system reboot (the pool did still exist however so i was curious as to what caused the storage pool not to be mounted after reboot).

The trick is that you can't put the backing store for a ZFS pool in an automounted directory and have it come up at boot time 'cuz the automounter doesn't start until after the "zfs mount" runs.
My investigation didn't take that long (actually i found this cause reasonably quickly by using the svcs(1) utility).

In other words, create the 2 files for the storage pool anywhere but under /home and you'll be fine.

posted by Marco @ 21:15 0 comments