Wednesday December 21, 2005

There have been quite a few DTrace providers written since its release on the world, I know of at least Java, Perl, PHP & Ruby. I haven't yet heard of anyone implementing a DTrace provider for a pure functional language like Haskell or even an impure one like LISP.

It has been quite some time since I hacked on any Haskell code, or any other pure functionaly language, and only slightly longer since I last hacked on any of the internals or standard libraries of GHC: Glasgow Haskell Compiler. But I have this really strange urge at the moment to write a DTrace provider for Haskell. At the moment I'm not even sure what a DTrace provider for GHC would allow me to do - partly because it will take a little while to kick my brain back into thinking about coding in a pure functionaly language again.

So don't expect to

dtrace -n 'ghc::: { ... }'

Wednesday November 16, 2005

This driver supports WEP encryption and uses the OpenSolaris kernel crypto framework (KCAPI) to get access to the RC4 (aka ArcFour due to RSA Security Trademarks) encryption algorithm.

Specifically it uses the crypto_encrypt_*() set of function calls.

Tuesday October 25, 2005

Courtesy of PlanetSun.org I just read on Alan Bateman's blog that the Mustang release of Java adds support for a getpassphrase(3c) like interface. Finally! Whats more it even does the java equivalent of using /dev/tty.

This is long over due, glad to see it is finally here!

Now that we have it I have to discourage people for using it, instead most of the time it is better to use the JAAS APIs in your applications and let the JAAS providers deal with getting the creds for you.

Technorati Tag: Java
( Oct 25 2005, 08:24:42 PM BST ) Permalink Comments [0]

Friday October 14, 2005

There are 3 basic usage styles for using OpenSolaris RBAC to give out privilege to "normal" users.

Privileged Command/Daemon: Authorisation Checks

In this style the app (or the daemon) would use RBAC Authoristaions to do the checking and then use its privilege on behalf of the end user.

In this case all the user needs to do is run the program as normal, no authentication is needed and the process doing the exec doesn't need to know anything special.

Privilege on Exec

The command is available for users to exec but it is not setuid, either because it has an unprivileged use and a privileged one or it only makes sense to be run with privilege. ifconfig is a good example of the former - users can view but not modify. ufsdump would be an example of the later.

In this case to take advantage of RBAC the execing process needs to exec the program using pfexec(1) rather than just doing the exec itself, for example:

   alice@host$ ifconfig -a

   alice@host$ pfexec ifconfig bge0 unplumb

The first runs without privilege given by RBAC, the second runs with it.

The calling application doesn't need to know anything about what privileges need to be set or what uid/gid it runs as, just use pfexec in your exec(2) call.

If the users shell is one of /bin/pfsh, /bin/pfksh, /bin/pfcsh the the pfexec [2] is implicit and ALWAYS used. Note that this ONLY applies to commands run via the shell - so it doesn't work with stuff started by something like the gnome panel.

The profile shells are just the same code as the normal shell, but when running in profile shell mode they do a little caching to determine if the command that is about to be run is one that has an RBAC exec_attr entry for this user, if it does then they exec it via pfexec. Note that this caching can help performance but it can also hinder additions to the RBAC profiles being noticed as they are made (but there are so many layers of caching of nameservice data this probably isn't worth worrying about).

Roles: Shared Account / Explicit Authentication model

Similar to case to but here we involve a role. The difference between this case and case 2 is there is an explicit authentication step involved and a new shared account. A role is just a shared account that cannot be logged into directly. Roles by default have a profile shell as their login shell.

   alice@host$  su - netadm
   Password: ********
   netadm@host$ dladm delete-aggr 1

In this case Alice had to explicitly become the netadm role then the netadm role (which has /bin/pfsh) run the command with the implicit pfexec.

So which style should you be using ?

It depends. There are no roles in Solaris by default; but there are profiles that could very easily map to system, network, security administrators and an operator. The root account can also be made a role.

What shouldn't you do ?

Tuesday October 04, 2005

Solaris Express Developer Edition (snv_24) includes a new feature in the assembler (/usr/ccs/bin/as) that automatically inserts an ELF section that identifies if any hardware specific features have been used. One example of this would be the use of SSE or MMX instructions on x86 systems. Prior to snv_24 it one had to manually tag the binaries using a linker mapfile.

This is a great feature since it greatly assists in the creation of $HWCAP libraries, such as optimised versions of libc that can use SSE and MMX or other CPU specific features.

The intergration of it did cause a minor problem though, 6330877. If you build the OpenSolaris source on a machine running snv_24 (specifically with /usr/ccs/bin/as from snv_24) there are are two binaries for x86 (32 bit) that now get tagged with SSE2 MMX required that didn't before. Those two binaries are kernel/crypto/rsa and usr/lib/security/pkcs11_softtoken.so.1. The tagging is correct, those to binaries include SSE2 and MMX code - they have done for quite some time now. Thanks to Bill Sommerfeld for finding this.

However we had been very careful and did a runtime check to determine if the CPU we were running on could run SSE2 and MMX and did not use a linker mapfile to tag our binary. This ensured that krtld and ld.so.1, via dlopen(3c), would still load the binaries. The reason we had done this was that there was only a single .o file that needed SSE2 and MMX and at that time it was overkill to build a set of $HWCAP variants for pkcs11_softoken.so.1. In addition we needed the detection code for the kernel anyway since krtld doesn't have the $HWCAP concept that its useland counter part has [ I'd like to see this happen and might start working on it soon since I have some more use cases comming up ].

The tagging of these binaries when built with the snv_24 /usr/ccs/bin/as meant that the runtime linker wouldn't load them. This means that anything using PKCS#11 is broken, this means Kerberos, IKE, SSH with GSS-API auth (since that likely uses Kerberos) and even simple things like digest(1).

The obvious solution might be to use mcs(1) or similar to just remove the .SUNW_cap section. In many cases that will work fine, but for the specific case of pkcs11_softtoken.so.1 and kernel/crypto/rsa it won't work. This is because these binaries are signed ELF objects. For all signed objects except for the plugins to the crypto framework we only sign the content that impacts program execution (basically the anything marked SHT_PROGBITS), this would mean that removing .SUNW_cap would have no impact on the signature. However for the crypto framework plugins we include all sections that existed at the time of signing; we do this because this is what we told the US govt we would do - comes from needing to commit to the design a little too early due to the lead times for US export approval.

So short or replacing the kernel/crypto/rsa and pkcs11_softtoken.so.1 binaries with ones from a previous release there isn't much you can do to fix up a system with these broken bits. Luckliy we haven't updated the ON gate machine that is used for Solaris Nevada to use the snv_24 linker yet - it is running the nightly bits from the ON consolidation but /usr/ccs/bin/as is delivered by the compiler tools group.

The longer term fix for userland is to extra the raw crypto out of pkcs11_softtoken.so.1, leaving it just being PKCS#11 code, and have it in a separate library that has $HWCAP variants. For the kernel we need to add $HWCAP processing to krtld or do something similar. That isn't a trivial change, its mostly Makefile work though. I already have this in progress for the digest algorithms in the form of libmd; that has almost finished code review and should be in OpenSolaris build 26. Once I've finished libmd I can start on doing the same thing for the symetric and asymetric crypto - the asymetric one being the urgent case here since it is only the BIGNUM code that uses SSE2 and MMX at this stage.

The short term fix, that will also go into OpenSolaris build 26, is to bring the linker to the rescue. That same mapfile trick we were forced to use in the past to tag the binaries we can use to override the automatic tagging provided by the assembler.

Here's the short term fix diffs

------- usr/src/common/bignum/i386/cap_mapfile -------

--- /dev/null   Thu Oct  6 08:58:12 2005
+++ /export/build/darrenm/6330877/usr/src/common/bignum/i386/cap_mapfile       Thu Oct  6 08:38:39 2005
@@ -1,0 +1,30 @@
+#
+# CDDL HEADER START
+#
+# The contents of this file are subject to the terms of the
+# Common Development and Distribution License, Version 1.0 only
+# (the "License").  You may not use this file except in compliance
+# with the License.
+#
+# You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+# or http://www.opensolaris.org/os/licensing.
+# See the License for the specific language governing permissions
+# and limitations under the License.
+#
+# When distributing Covered Code, include this CDDL HEADER in each
+# file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+# If applicable, add the following below this CDDL HEADER, with the
+# fields enclosed by brackets "[]" replaced with your own identifying
+# information: Portions Copyright [yyyy] [name of copyright owner]
+#
+# CDDL HEADER END
+#
+# Copyright 2005 Sun Microsystems, Inc.  All rights reserved.
+# Use is subject to license terms.
+#
+# ident        "@(#)cap_mapfile        1.1     05/10/06 SMI"
+
+# Override the insertion of SSE2/MMX tags into .SUNWcap since we do a
+# runtime check for this and don't need the loaders help.
+# Note that this overrides all HWCAP tags not just SSE2/MMX.
+hwcap_1 = V0x0 OVERRIDE;

------- usr/src/lib/pkcs11/Makefile.softtoken.i386 -------

Index: usr/src/lib/pkcs11/Makefile.softtoken.i386
--- /ws/onnv-gate/usr/src/lib/pkcs11/Makefile.softtoken.i386    Sat Jun 11 17:39:22 2005
+++ /export/build/darrenm/6330877/usr/src/lib/pkcs11/Makefile.softtoken.i386   Thu Oct  6 08:38:39 2005
@@ -20,10 +20,10 @@
 # CDDL HEADER END
 #
 #
-# Copyright 2004 Sun Microsystems, Inc.  All rights reserved.
+# Copyright 2005 Sun Microsystems, Inc.  All rights reserved.
 # Use is subject to license terms.
 #
-# ident        "@(#)Makefile.softtoken.i386    1.2     05/06/08 SMI"
+# ident        "@(#)Makefile.softtoken.i386    1.3     05/10/06 SMI"
 #
 # lib/pkcs11/Makefile.softtoken.i386
 #
@@ -44,6 +44,8 @@

 install: all $(ROOTLIBS) $(ROOTLINKS)

+DYNFLAGS += -M $(BIGNUMDIR)/i386/cap_mapfile
+
 pics/bignum_i386.o := COPTFLAG = -xO3

 pics/%.o:      $(BIGNUMDIR)/$(MACH)/%.c

------- usr/src/uts/intel/rsa/Makefile.32 -------

Index: usr/src/uts/intel/rsa/Makefile.32
--- /ws/onnv-gate/usr/src/uts/intel/rsa/Makefile.32     Sat Jun 11 17:46:24 2005+++ /export/build/darrenm/6330877/usr/src/uts/intel/rsa/Makefile.32     Thu Oct  6 08:38:40 2005
@@ -20,10 +20,10 @@
 # CDDL HEADER END
 #
 #
-# Copyright 2004 Sun Microsystems, Inc.  All rights reserved.
+# Copyright 2005 Sun Microsystems, Inc.  All rights reserved.
 # Use is subject to license terms.
 #
-#ident "@(#)Makefile.32        1.3     05/06/08 SMI"
+#ident "@(#)Makefile.32        1.4     05/10/06 SMI"
 #
 #      Configuration and targets for RSA KEF provider
 #      specific to Intel 32-bit architecture, i386.
@@ -42,6 +42,8 @@

 BIGNUM_CFG = -DPSR_MUL -DHWCAP -DMMX_MANAGE

+LDFLAGS += -M $(BIGNUMDIR)/i386/cap_mapfile
+
 $(OBJS_DIR)/bignumimpl.o $(LINTS_DIR)/bignumimpl.ln := \
        CPPFLAGS += $(BIGNUM_CFG)
 $(OBJS_DIR)/bignum_i386.o $(LINTS_DIR)/bignum_i386.ln := \

Wednesday September 21, 2005

# /usr/dt/bin/dtconfig -kill
# /usr/dt/bin/dtconfig -d
# ((sleep 5 && svcadm enable -s gdm2-login)&) ; exit

Update for snv_20 aka Solaris Express Community Release Build 20

As of snv_20 the work previously done by /etc/init.d/dtlogin is now converted to a set of SMF services. As such the new proceedure would be:

# svcadm disable -s dtlogin
# svcadm enable gdm2-login ; exit

Friday August 19, 2005

It seems to be a little known fact that pkgadd in Solaris can actually download and install packages for http and https. This functionality was first added in an update release of Solaris 9 as part of the WAN Boot/Install project. Details of WAN booting and install can be found in this section of the online documentation.

Basically it amounts to being able to do this:

Where the package is in stream format (see pkgtrans(1) for details on how to create stream format packages.

Technorati Tag: Solaris

Monday July 18, 2005

Casper Dik posted recently about frkit and mentioned that there was a GNOME applet for the battery status driver. I was the one that did the port of the existing GNOME battery status to the acpidrv driver that is in the frkit bundle.

You can download the frkit bundle for the gnome applet here. This contains the source and binaries, the source is hacked in and doesn't support GNU autoconf because I haven't spent the time to understand how it is supposed to work.

I've also posted the patches and request for official Solaris x86 support to the GNOME bugzilla bug# 302886. Longer term the correct way to do this is to get HAL ported over to Solaris since this benefits GNOME & KDE. I believe the Desktop community of OpenSolaris will be starting that port. Once we have that done and the real interface to the battery status is implemented we can have a much cleaner solution. In the mean time my hacked up applet will do.

Friday June 17, 2005

There a few frameworks in Solaris that have configuration files that store the paths to shared libaries that need to be dlopen()'d at runtime. Prior to Solaris 7 this was easy you just stored the path the the file. When Solaris 7 introduced 64bit SPARC userland libraries some of these frameworks already existed and thus needed a solution that allowed a single config file to be used for both 32 and 64 bit libraries. The PAM framework (libpam) has an admin editable config file that now needed to work for both 32 and 64 bit libraries, yet it supported having full paths in the config file (in fact the file shipped with Solaris at that time had full paths in it even though there was a default of /usr/lib/security).

The solution that was used in libpam and has since been copied by various other parts of the system, including crypt(3c) was to use the "magic" token $ISA to mean, expand to empty on 32 bit SPARC and sparcv9 on 64 bit SPARC. When we did the port to AMD64 all of these needed to be updated to reflect that amd64 was the subdir that was needed instead of sparcv9 when running on the x64 platform. Instead of hardcoding amd64 it was changed to "64" and symlinks added for SPARC that has 64 -> sparcv9 and AMD64 64 -> amd64.

Technorati Tag: OpenSolaris
Technorati Tag: Solaris

Tuesday June 14, 2005

usermod: ERROR: username is in use. Cannot change it (for 9 years!)

I thought some people might find this small bug fix interesting now that OpenSolaris is open for business to all. It is in those class of things that really only get fixed because it anoys an engineer so much one day that they fix it. The problem with is one was this had been the behaviour since day one (SunOS 5.0) and the bug (1236941) was logged on 1996-02-02 and marked as an RFE. It had be evaulated in 1998-03-18 and marked as fix understood. Being an RFE and in a not very critical part of the code it just never got fixed.

I recently (2005-04-29) fixed it as a BUG, which is what it really was. The introduction of RBAC in Solaris 8 really pushed this from being midly anoying to a blatent bug, it mean I couldn't make root a role without editing /etc/user_attr directly. More importantly it meant I couldn't add profiles or authorisations to a role to give a user more access while they were logged in.

I fixed this because it was anoying users of my (currently internal but soon to appear externally) netprof package. In the postinstall of my package I ask for the username of the laptop primary user and attempt to use usermod(1M) to add the RBAC 'Network Administrator' profile to that account.

If the user was logged in and had su'd to root to add the package or had used pfexec pkgadd (with the Software Installation profile) and users couldn't use netprof out of the box. This resulting in so many emails over a period of a few months that I decided to fix usermod.

I actually did the fix on my laptop while in Tokyo giving the Solaris 10 TPT training. This is a nice simple case that shows how valuable the partial bringover feature of teamware can be sometimes all I needed in the workspace was $SRC/cmd/oamuser.

There are still some cases were we don't allow a change if the user is logged in. The following comment in usermod.c explains those cases:

        /*
         * We can't modify a logged in user if any of the following
         * are being changed:
         * uid (-u & -o), group (-g), home dir (-m), loginname (-l).
         * If none of those are specified it is okay to go ahead
         * some types of changes only take effect on next login, some
         * like authorisations and profiles take effect instantly.
         * One might think that -K type=role should require that the
         * user not be logged in, however this would make it very
         * difficult to make the root account a role using this command.
         */

The fix was really quite simple, it was really just making sure that we only call isbusy() when we were doing something that has critical impact the the account, for example chaning its uid/gid or loginname. I'm now wondering if changing the home dir should have been allowed, but for most people this is usually /home/ anyway. Which brings me to another bug in usermod that anoys me and others: 6244467

I need to check that smuser(1M) and smc(1M) don't have the same problem. Those tools aren't yet in opensolaris.org since they aren't in the ON consolidation but I expect they will arrive when the ADMIN consolidation arrives in opensolaris.org.

Technorati Tag: OpenSolaris
Technorati Tag: Solaris

If you are looking for crypto related code in OpenSolaris today you might be a little disapointed since not all of it is present yet. Let me assure you that we (me in particular) are working very hard to get it included. It is probably easiest to understand if I explain some history related to the Solaris source and what we intend to do about it so we can get you full access to the cryptographic frameworks and the algorithm implementations.

Even prior to the startup of the OpenSolaris program it was possible to get access to some of the source code of Solaris, how much you had to pay depended on what you intended to do with it and wither or not you were an academic instuition. Due to US export regulations all of the cryptographic algorithm implmentation and many cryptographic related plugin points into security frameworks had to have their interfaces obscured. This was because the source code was not open source and thus didn't get treated the same way as things like OpenSSL. If you were a domestic US customer it was possible to see the cryptographic algorithm implementations but still not some of the other things.

To achive this we put markers into many parts of the source to delimt things that needed to be removed, some times this was whole files, sometimes it was just parts of functions. We then have a special run of the nightly build script that builds two different versions of the source product, one for domestic US (CRYPT_SRC build) and one for export (EXPORT_SRC build).

Okay so how does this impact the crypto code ? Due to using the same mechanism to remove NDA code and code we previously couldn't release due to it being cryptographic source in a non open source licensed product we have a time consuming task of now unwinding these things. It is this thing that I and my colleagues are working on, we just didn't have enough time to complete this before today.

So whats the plan for getting access to the crypto code ? For the short term (read the next couple of days) we hope to get an additional download file put up that contains the missing cryptographic algorithm implementations and the missing bits of security frameworks (eg some bits of libgss and libsasl). For the longer term this code will be treated just like the rest of OpenSolaris visible source code and it will be browsable, buildable and downloadable just like usr/bin/ls and friends.

Technorati Tag: OpenSolaris
Technorati Tag: Solaris

Thursday June 02, 2005

The other presentation at the Bay Area OpenSolaris users group this week was a demonstration of Looking Glass running on a Solaris laptop. This demonstration took advantage of the new nVIDIA drivers for the Xorg server on Solaris 10. It was a fantastic demo and I'm so glad to see Looking Glass running on Solaris. This new driver also brings multi head support from a single card and TV out, something that the opensource ATI driver can do but the nVIDIA one can't.

Okay ATI the ball is in your court, I want Looking Glass on my Ferrari 3400 so I need 3D & OpenGL for the Radeon Mobility 9700 as well!

Wednesday June 01, 2005

Last night I gave a presentation that I titled "OpenSolaris for security geeks" at the OpenSolaris user group on the Sun Santa Clara campus. This presentation will make a bit more sense once the code for OpenSolaris is visible to everyone (it has paths to where in the source tree you find certain functionality). For now I'll put up the PDF that I presented last night. It covers privileges and the cryptographic framework in more detail than most other stuff. Once we go live with the code of OpenSolaris (real soon now, I'm told!) I'll repost with the paths converted to URLs so you can go direct to the place in the source.

Technorati Tag: OpenSolaris
Technorati Tag: Solaris

Thursday February 10, 2005

#!/bin/ksh
exec $(gconftool-2 -g /desktop/gnome/applications/browser/exec) "$@"

Tuesday November 16, 2004

Solaris 10 introduces new linker/loader hardware capabilities support. We have 3 different versions of libc for Solaris x86, the old one we had before plus two new ones.

$ psrinfo -pv
The physical processor has 1 virtual processor (0)
  x86 (GenuineIntel family 6 model 9 step 5 clock 1700 MHz)
        GenuineIntel 6.9.5

$ isainfo -v
32-bit i386 applications
        sse2 sse fxsr mmx cmov sep cx8 tsc fpu

$ psrinfo -pv
The physical processor has 1 virtual processor (0)
  x86 (AuthenticAMD family 15 model 5 step 10 clock 2391 MHz)
        AMD Opteron(tm) Processor 850
The physical processor has 1 virtual processor (1)
  x86 (AuthenticAMD family 15 model 5 step 10 clock 2391 MHz)
        AMD Opteron(tm) Processor 850
The physical processor has 1 virtual processor (2)
  x86 (AuthenticAMD family 15 model 5 step 10 clock 2391 MHz)
        AMD Opteron(tm) Processor 850
The physical processor has 1 virtual processor (3)
  x86 (AuthenticAMD family 15 model 5 step 10 clock 2391 MHz)
        AMD Opteron(tm) Processor 850

$ isainfo -v
64-bit amd64 applications
        sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx mmx cmov amd_sysc cx8 tsc
        fpu
32-bit i386 applications
        sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx mmx cmov amd_sysc cx8 tsc
        fpu

search

recent entries

• SMF service notification "applet"
• File notification in OpenSolaris - and a bit of shell internals
• Sending a Break to OpenSolaris hosted in Virtualbox
• (Secured) Remote Audit Trail in OpenSolaris
• TVOSUG First Meeting tonight (Mon 6th July)
• printf should not SEGV when passed NULL for %s format
• Encrypting ZFS pools using lofi crypto
• Running Privileged Applications in the OpenSolaris GNOME Desktop
• ZFS Crypto Update
• OpenSolaris "disk" encryption in snv_105

navigation

links

rss feeds