Tuesday Aug 12, 2008

What is the maximum password length for Solaris/OpenSolaris ?

I find I'm answering this question a lot on our internal support aliases. Simply out the maximum possible length is 255. However it actually depends on the algorithm that crypt(3C) is going to use. Starting in the second update release of Solaris 9 we made crypt(3C) pluggable.

Not all crypt(3C) plugins accept the full 255 chars as significant input. The documented limit for each of them is on the relevant man page but I'll summarise here:

  • crypt_unix(5) - the old unix default (8)
  • crypt_sunmd5(5) - S9u2 onwards - (255)
  • crypt_bsdmd5(5) - S9u2 onwards - (255)
  • crypt_bsdbf(5) - S9u2 onwards - (255)
  • crypt_sha256(5) - S10u6 / OpenSolaris onwards - (255)
  • crypt_sha512(5) - S10u6 / OpenSolaris onwards - (255)

How to do this is documented here: Solaris 10 System Administrator Collection >> System Administration Guide: Security Services >> System, File, and Device Security >> 3. Controlling Access to Systems (Tasks) >> Changing the Password Algorithm (Task Map)

Friday Jul 25, 2008

T5120 donated to Haskell Community

I just spotted on Darryl Gove's blog that Sun has donated a T5120 to the Haskell community. Fantastic. The goal is investigate how GHC (The Glasgow Haskell Compiler) can take advantage of the CMT architecture of the T5120.

Ah good old GHC that takes me back (ghc on SunOS 4.1.3 on sun4m!). I wonder if any of my code is still in the GHC libraries. This is a fantastic announcement. I've been thinking for a while now I'd like to get back to doing some Haskell programming and I've been considering adding DTrace probes to GHC - because I just feel it should have them!

Almost makes me want to be a student back at Glasgow again so I could work on it, I liked Haskell and I had a fun summer after graduation working on GHC

Thursday Jul 24, 2008

Enabling OpenSolaris Auditing without Device Allocation

Today I needed to enable auditing on my OpenSolaris system to check some audit behaviour. However I didn't want device allocation enabled, I do want mass storage devices to still be automatically mounted particularly since I was doing this on my laptop, and also because I wasn't interested in anything other than the events in the 'lo' or 'ss' class (login/logout and system state change).

When bsmconv is run it turns on auditing (on next reboot) and disables the automatic mounting of mass storage devices. The later it does by updating the HAL configuration. I creates /etc/hal/fdi/policy/30user/90-solaris-device-allocation.fdi, this is an XML format file that HAL reads when it starts up.

So the simple fix to have auditing but not device allocation is this:

islay$ pfexec bsmconv   # Answer y
islay$ pfexec rm etc/hal/fdi/policy/30user/90-solaris-device-allocation.fdi

We really should split these things a part like we have been planning to do for quite some time.

Thursday Jun 26, 2008

A TX window without a label ? Opps ?

What is going on here ?

Surely that editor window on the right hand side is a problem it doesn't have a sensitivity label on it ?

Answer is in the next picture:

This was a screenshot of Trusted Extensions running in VirtualBox with Seamless Windows mode turned on.The host was OpenSolaris 2008.05 (snv_91). Where I'm going next is to do it other other way around, so that the host is TX and the guest is also TX but with different label encodings.

What this does show is that even when TX is running as a virtualised guest the MLS enforcement for cut and paste still applies. The host was treated as "Trusted Path", which makes perfect sense in this case because it is the "hardware".

Friday May 23, 2008

VNC as OpenSolaris 2008.05 console

Changing OpenSolaris 2008.05 to use Xvnc for the default X server rather than Xorg is really simple. OpenSolaris 2008.05 uses GDM as the graphical login manager. GDM starts the X server using /usr/X11/bin/X (a symlink to Xserver). The Xserver program in /usr/X11/bin uses SMF to store its configuration properties. This includes the location of the "real" (or "virtual" in our case) X server program.

To switch to Xnvc:

$ pfexec svccfg -s x11-server 
svc:/application/x11/x11-server> setprop options/server = "/usr/X11/bin/Xvnc"
svc:/application/x11/x11-server> setprop options/server_args = astring: ("-SecurityTypes" "None")
svc:/application/x11/x11-server> setprop options/tcp_listen = true
svc:/application/x11/x11-server> end
$ pfexec svcadm restart gdm

Now use your VNC client to connect using the IP address of your OpenSolaris machine. You will get the OpenSolaris login screen. Note that we disabled VNC level security above, so lets now change things so that VNC only works over SSH port forwarding. We do this by telling the Xvnc server to only listen locally.

$ pfexec svccfg -s x11-server
svc:/application/x11/x11-server> setprop options/server_args = astring: ("-SecurityTypes" "None" "-localhost")
svc:/application/x11/x11-server> end
$ pfexec svcadm restart gdm

Now to connect we need to do somethink like this:

remotehost$ ssh -n -f -L5900:localhost:5900 opensolarishost sleep 100
remotehost$ vncviewer localhost

To switch back to a local X server:

$ pfexec svccfg -s x11-server 
svc:/application/x11/x11-server> setprop options/server = "/usr/X11/bin/Xorg"
svc:/application/x11/x11-server>setprop options/server_args= ""
svc:/application/x11/x11-server> setprop options/tcp_listen = false
svc:/application/x11/x11-server>end
$ pfexec svcadm restart gdm

Wednesday Apr 30, 2008

Simple CLI based CA on Solaris

With the recently added ability to sign PKCS#10 certificate request files the pktool(1) command of OpenSolaris can be used as a very simple Certificate Authority, similar to what can be done with the openssl(1) command but in my opinion in a much clearer way and actually providing stronger security. I'll outline the basic commands below but some external "database" will be needed to keep the serial number count and some other state needed to be a useful CA.

First Generate root CA - this is by definition self-signed

admin$ pktool gencert keystore=file outcert=myCA \\
  subject="CN=test,DC=EXAMPLE,DC=COM" serial=0x1 outkey=myCA.key

Generate a user CSR in PKCS#10 format

user$ pktool gencsr keystore=file outcsr=sample.p10 \\
  subject="CN=darren,OU=people,DC=EXAMPLE,DC=COM" outkey=sample.key
The user then sends the PKCS#10 certificate request to the administrator for signing.

Sign the PKCS#10 CSR with the root CA

admin$ pktool signcsr keystore=file signkey=myCA.key csr=sample.p10 \\
  outcert=sample.cert format=pem serial=0x1001
  issuer="CN=small-CA,DC=EXAMPLE,DC=COM"

Increasing the CA security

The above example stores the master CA key in a file but we can do better than that and store it in a PKCS#11 accessible hardware keystore. It would looks something like this:
admin$ pktool gencert keystore=pkcs11 label=myCA \\
  subject="CN=test,DC=EXAMPLE,DC=COM" serial=0x1
Enter PIN for Sun Software PKCS#11 softtoken  : 

We now have the key in a PKCS#11 accessible keystore that is PIN protected, the sign operation is almost the same:

admin$ pktool signcsr keystore=pkcs11 signkey=myCA  csr=sample.p10 \\
  outcert=sample.cert format=pem serial=0x1001 \\
  issuer="CN=small-CA,DC=EXAMPLE,DC=COM"
Enter PIN for Sun Software PKCS#11 softtoken  :

Note that we didn't explicitly specify the PKCS#11 token to use but pktool(1) allows us to do so.

Similarly the user can use a PKCS#11 keystore when they run gencert.

Friday Jan 04, 2008

Migrating a Teamware workspace to OpenSolaris.org hosted Mercurial

Casper just asked me: "How do you put your own project workspace on opensolaris.org?. So I wrote up email describing how I do it. Since I thought it might be useful I've included a slightly reworded version of it here.

It has to be in either Mercurial or SubVersion. If it is a project targeting the ONNV consolidation then Mercurial is the choice.

First create a local clone of the Mercurial onnv-gate like this:

    $ hg clone ssh://anon@hg.opensolaris.org/hg/onnv/onnv-gate myproject

Make sure your Teamware gate is at the same point. Now do a 'wx backup' of your teamware workspace.

Untar the ??.clear.tar file from the wx backup directory into the myproject directory.

Check this still builds - it should but you will need to get the closed-bins tar file that match your clone of onnv-gate since you don't have usr/closed.

If it all built find commit this to your local repository

$ hg commit

You now need to create a repository on opensolaris.org to host this. In your project page there is an "SCM Management" link that is shown only to project leads. Click that. On the left hand nav-column there will then be a link "Add Repository". Fill in the form.

The Anonymous here means allow anyone to pull from the repository, if you don't tick that then only people with an opensolaris.org account with loaded ssh keys can do a pull (I generally allow it as do most projects I believe). Project leads can always do a push, and you can delegate that to people who are listed as observers too.

The name you give is tagged on the end of your project URL. So if you say "gate" you will end up with:

    "ssh://hg.opensolaris.org/hg/fgap/gate"

The notification email gets every push message, so choose wisely what you set this too. Some projects use a dedicated -notify@ alias others just use their -discuss@ alias.

You are now ready to push your changes so lets configure your local copy of your Mercurial repository with the paths. Add the following to the .hg/hgrc file in your myproject dir:

[paths]
default=ssh://username@hg.opensolaris.org/hg/myproject/gate
default-push=ssh://username@hg.opensolaris.org/hg/myproject/gate
onnv-gate=ssh://anon@hg.opensolaris.org/hg/onnv/onnv-gate

Now lets do the push:

$ hg push

You now have a populated repository on opensolaris.org. To do a resync with onnv-gate you do something like this:

# Make sure you are in sync with the fgap project gate
$ hg pull
# Merge if needed
$ hg merge

# Now pull in the onnv-gate changes
# if you want a specific build you can say -r onnv_80 after the pull
# Note this uses the path alias we defined above to avoid using the full URL
$ hg pull onnv-gate
$ hg merge
$ hg commit
$ hg push

Hope this helps.

Note that for all this push/pull to work as your user you need to have your ssh pubkey uploaded for opensolaris.org. If you have ever voted you have done that already.

Thursday Oct 04, 2007

ZFS Crypto Alpha Release

ZFS Crypto (Phase 1) Alpha Release binaries are now available. At the moment this is x86/x64 only and debugging a very strange (non crypto) problem on the SPARC binaries and will make them available when I can.

Friday Aug 03, 2007

New Linux scheduler old Solaris one(s)

I find it interesting and slightly sad, given how low level a topic this really is, how much is being written about the new CFS scheduler being introduced into Linux. The sad part is how much flamage is flying around as a result of this from people not in the slightest bit involved in the desgin and development - this sadly is the ugly side of many open source groups.

OpenSolaris has multiple scheduling classes as well, actually Solaris had this and OpenSolaris inherited it when the source was opened up - but there is active work in this area going on, and the ability to realtively easily add more. You can also change the dispatch tables of the existing ones - even on a live running system (see dispadmin(1M) and ts_dptbl(4)

For some more info on how OpenSolaris does scheduling and how it is integrated into the rest of the resouce management system see this excellent intro to the topic by Eric Saxe.

As you hopefully see from Eric's presentation the scheduler is only a small part of the over all resource management issue and ensuring fairness. OpenSolaris builds on the scheduler by using things like processor pools. I particularly like the Fair Share Scheduler (FSS) class. The Sun Ray server that I use at work (and at home via VPN) uses FSS so that users can't dominate the server cpu resources.

I find it very cool that you can even use different scheduling classes for zones (actually you can do it per process but mixing FSS with TS/IA in a given processor pool isn't recommended). If all that wasn't cool enough all the policy for FSS (and much other projects stuff related to resource management) can be stored in LDAP so it is easy to implement a network wide policy.

Friday Jul 27, 2007

pam_radius_auth Sun Studio patch

The following is a small patch to the FreeRadius pam_radius_auth source to allow it to compile with the Sun Studio compiler and the Solaris linker.  It also changes the resulting module to use the MD5 functions from libmd rather than its own local copy.

--- pam_radius-1.3.17/Makefile  Mon Mar 26 05:22:11 2007
+++ pam_radius-1.3.17-djm/Makefile      Fri Jul 27 11:16:32 2007
@@ -15,7 +15,8 @@
 #
 #  If you're not using GCC, then you'll have to change the CFLAGS.
 #
-CFLAGS = -Wall -fPIC
+#CFLAGS = -Wall -fPIC
+CFLAGS = -KPIC
 #
 # On Irix, use this with MIPSPRo C Compiler, and don't forget to export CC=cc
 # gcc on Irix does not work yet for pam_radius
@@ -54,8 +55,9 @@
 #
 #      gcc -shared pam_radius_auth.o md5.o -lpam -lc -o pam_radius_auth.so
 #
-pam_radius_auth.so: pam_radius_auth.o md5.o
-       ld -Bshareable pam_radius_auth.o md5.o -lpam -o pam_radius_auth.so
+pam_radius_auth.so: pam_radius_auth.o
+#      ld -Bshareable pam_radius_auth.o md5.o -lpam -o pam_radius_auth.so
+       ld -G pam_radius_auth.o -lmd -lpam -o pam_radius_auth.so
 
 ######################################################################
 #

Note that with this patch you will still get warnings when compiling the pam_radius_auth.c file due to differences in the function prototypes for libpam functions such as pam_get_item().  The pam_radius_auth.c assumes that const void \* is used for some function arguments in libpam, on Solaris some of these are const char \*.  These warnings can be  ignored. 
 

Tuesday Jul 10, 2007

Niagara Random Number Driver source opened

"6543566 RNG does not need to be in closed source" got integrated recently but for some reason I forgot to post this (it has been sitting as a draft for a while, oops).  
This means that the OpenSolaris Crypto Framework driver for the on CPU chip
Niagara 2 is now available from OpenSolaris under the CDDL as another good
example of how to write a plugin for the crypto framework.

When OpenGrok gets updated on the next pass you can see it at this link.

Monday Jul 02, 2007

ZFS Crypto Design Review

The design review for phase one of the OpenSolaris ZFS Crypto Project starts now, details on how to participate are here.

 

Tuesday May 15, 2007

Solaris Express build 64: security features update

I've upgraded my laptop from build 61 of Solaris Express to build 64 yesterday.  A few nice security features have integrated since then and the first delivery of the Network Automagic (NWAM) project.  I'd been using NWAM for quite some time now but this was the first chance I've had to use it with WPA (which I wrote about here). 

I tried a little experiment to see how automatic NWAM can be in the face of things like WPA.  So I set my router/AP to open (with MAC restriction still on) and let NWAM connect my laptop to my local LAN.  No problems.  From another machine I then changed the router/ap to use WPA and set a PSK passphrase.  As soon as I hit apply Solaris notices the connection drop and after a few seconds NWAM pulled the interface down.  Once NWAM scanned again (which by default is every 2 minutes) I got prompted graphically for the WPA passphrase for my network.  Entered it in and I was reconnected.  No bringing up preference panels or reconfiguring anything, all just automatic.   If I choose to use wired ethernet instead I just plug in the cable and NWAM automatically switches to wired ethernet.

When I started up GAIM (snv_64 still has 2.0.0beta4 not Pidgin yet) I got prompted to create a GNOME keyring master password.  GAIM migrated all my IM and IRC account passwords into the GNOME keyring.  I ranted about this previously, glad to see that in Solaris Express builds we now use the GNOME keyring.

OTR for GAIM (or it might be Pidgin by then) is in the works as well.

 

Wednesday May 02, 2007

ZFS under GPLv2 already exists - no kidding!

I'm getting really fed up with the constant rantings on all sides about what Sun should to about the license on the ZFS code so that Linux can use it.  Apparently Sun is the bad guy because ZFS is under CDDL and not GPLv2 and we are purposely doing that so Linux does not get ZFS, personally I don't agree but each to their own opinion and licensing is worse than religion in open software development. 

There is already a port to FreeBSD and rumours abound that it is in a future release of MacOS, without the CDDL those might not have happened. 

There is also a port of ZFS to FUSE which means Linux users can use it that way.  Performance won't be great with FUSE but it is probably acceptable.  FUSE is a great tool and I can't wait until the Solaris port is ready - because then Solaris can read Linux ext based filesystems that way!

Now about that headline, yes I really did say that ZFS code is already available under the GPLv2.  I will be completely honest though and make it clear that it isn't all of the ZFS source.  It is, sufficient amount to be able to boot an OpenSolaris based system from GRUB, that means that support for mirroring and the checksum and compression support is there but radiz isn't nor are the userland commands.   It is possible that this might be enough to get someone started.  Still don't believe me check out the updated GRUB source on opensolaris.org, specifically all the files with zfs in their name - every single one of them under the GPLv2 or later.

Update:  While I appreciate some of the comments posted I'm not going to let my blog be a place to post other peoples opinions on CDDL vs GPL.  So I've deleted some comments, if that annoys you because I deleted your comment, tough luck this is my blog and my policy and thats how it is.  Comments are now closed.
 

Wednesday Apr 18, 2007

RBAC vs sudo HOWTO Part 1 of N: Running (all) commands as root

This is part 1 of N (where N is yet to be defined but I intend for N > 1) where I'm going to describe some sudo functionality and explain how to do the equivalent thing with OpenSolaris RBAC.   There won't always be an exact match because the functionality of sudo and RBAC doesn't line up 1:1, each can be configured to do things the other can't.  In general I'm going to try and show how to do things rather than trying to justify why RBAC or sudo do things they way they do.  Where relevant I'll point out how they differ in solving a particular task.

Lets start with an easy case.  I want to give the user 'darrenm' the ability to run any command as root using sudo but don't require them to authenticate.   Lets first implement this with sudo: in /etc/sudoers we add this entry:

darrenm ALL= NOPASSWD: ALL

Lets try a simple example to show it works:

islay:pts/4$ id -a
uid=35661(darrenm) gid=10(staff) groups=10(staff)
islay:pts/4$ sudo id -a
uid=0(root) gid=0(root) groups=0(root),1(other),2(bin),3(sys),4(adm),5(uucp),6(mail),7(tty),8(lp),9(nuucp),12(daemon)

Great that appears to be working.

Now lets see how to do the same thing with OpenSolaris RBAC. There is a pre-defined RBAC profile that allows a user that is granted it the ability to run any command with the uid and gid of root.  We use usermod(1M) to give that to our user.


# usermod -P'Primary Administrator' darrenm

Now lets try our simple test again:


islay:pts/4$ id -a
uid=35661(darrenm) gid=10(staff) groups=10(staff)
islay:pts/4$ pfexec id -a
uid=0(root) gid=0(root) groups=10(staff)

You will see that there is a subtle difference in the output of 'id -a', I explicitly passed the -a argument so that I could point out the difference between sudo and RBAC here.  In this case is is mostly irrelevant but sudo has done an explicit initgroups(3C) call so all of the root users
supplementary groups are setup as well.  The RBAC pfexec(1) command didn't do that it just changed the attributes defined in the RBAC profile, in this case that is just the real uid and gid the process runs under.

Lets look at how this was actually defined in RBAC: 

$ grep 'Primary Administrator' /etc/security/exec_attr
Primary Administrator:suser:cmd:::\*:uid=0;gid=0

This says that for all commands (thats the '\*') set uid and gid to 0.  Lets also see how it was assigned to the user:

$ grep \^darrenm /etc/user_attr 
darrenm::::type=normal;profiles=Primary Administrator

We could have manually edited /etc/user_attr (or the nameservice equivalent) rather than,running usermod as we did above.
Now all you need to do is retrain your fingers to type 'pfexec' as the prefix to commands you want run as root rather than prefixing 'sudo'.

Thats all for now.

About

DarrenMoffat

Search

Categories
Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today