Friday September 05, 2008

Prelim codereview for the OpenSolaris ZFS Crypto project starts today (Friday 5th September 2008 at 1200 US/Pacific) and is scheduled to end on Friday 3rd October 2008 at 2359 US/Pacific. Comments recieved after this time will still be considered but unless there are serious in nature (data corruption, security issue, regression from existing ZFS) they may have to wait until post onnv-gate integration to be addressed; however every comment will be looked at and assessed on its own merit.

For the rest of the pointers to the review materials and how to send comments see the project codereview page.

Some background

This is really only relevant to those people doing development on the OpenSolaris onnv-gate that are inside Sun, but it since there is nothing private about it I'm posting it publicly so google can find it.

With the transition from Teamware to Mercurial the onnv-gate source code is now held in two separate repositories. The main repository holding the overwhelming majority of the source code, which is opensourced under various licenses but mostly CDDL, is called "onnv-gate" the source code is in the mercurial repository in a subdirectory called usr/src. The much smaller closed source is in a separate repository that is nested inside the "onnv-gate" as the usr/closed subdirectory.

The usr/src part can be built either by using the downloadable (and redistributable) binaries which make up a proto area for the closed source bits, or the usr/closed part can be built from source along with usr/src. If building both from source then the usr/src and usr/closed mercurial repositories must be in sync otherwise there will be a high risk of either build failures or buggy binaries.

Initial gate setup

$ hg clone ssh://onnv.sfbay.sun.com//export/onnv-clone myrepo
$ cd myrepo/usr
$ hg clone ssh://onnv.sfbay.sun.com//export/onnv-clone/usr/closed

Syncing with onnv-gate

$ cd path/to/myrepo
$ hg fpull

You may find this a little slow as it has to traverse the whole workspace looking for nested repositories so it can build the definition of the forest. This can be speeded up using the "fsnap" command to create a snapshot file. Or you can create one by hand, that may look similar to this:

[tree1]
root = .
revision = tip
path.default = ssh://onnv.sfbay.sun.com//export/onnv-clone

[tree2]
root = usr/closed
revision = tip
path.default = ssh://onnv.sfbay.sun.com//export/onnv-clone/usr/closed

To use the snapshot file we run fpull like this:

$ hg fpull --snapfile /path/to/mysnapfile

ONNV-gate push rules

The rules for pushing to the onnv-gate when a single set of fixes needs to span the usr/src and usr/closed trees is that usr/closed must be pushed first. This basically means that you should NOT use the forest extension for pushing. However the number of people that this impacts is very small most developers just need an up to date usr/closed for building.

For this reason I'm not showing how to push with the forest extension here.

Via OSnews I came across a IBM article on KornShell 93 command auditing. Even before reading the article I viewed it with some caution. Why ? because you can't actually trust the shell to do what I know as auditing. Auditing of command execution "inside" the shell isn't sufficiently security and trustworthy, it has to be done in the TCB (Trusted Computing Base) of the OS (usually the kernel and some core system services in userland). The TCB is only place that really knows everything that was executed and the only place that really knows the credentials of the executing user.

All the user has to do to by pass shell level "auditing" is start a different shell, this is harder though if a restricted shell is being used. The other thing that concerns me with a shell level implementation is that when writing the log to a local file it needs to be able to be written to by the unprivileged user because ksh wouldn't be (well I hope not) installed setuid. This makes it considerably less trustworthy as the user can easily modify the log to remove or alter things.

Now compare this to the in kernel OpenSolaris/Solaris audit trail (that has been a part of SunOS in excess of 15 years); it is stored read/write only by root and the audit records are generated in kernel. Not only are the records generated in kernel the identity of the original logged in user (we call this the audit uid) is preserved even over multiple su(1M) commands or calls to setreuid() - something shell level "auditing" can't do.

The Solaris in kernel auditing does much more than just audit exec(2) calls and provides an audit trail for all security sensitive (ie any time privilege or access descisions are made) operations. In addition to kernel provided audit records privileged programs (those running with proc_audit on Solaris 10 or later or those running as uid 0 on earlier releases) such as the SMF service daemons or the SMC admin system can also write higher level "application specific" audit records, eg sevice start, user added/modified.

To configure OpenSolaris to log just the commands that users run is relatively simple. First turn on auditing by running /etc/security/bsmconv. Then in /etc/security/audit_control add "ex" to the flags line. If you want command arguments as well as the command names then add "/usr/sbin/auditconfig -setpolicy +argv" to /etc/security/audit_startup. You can also enable logging of the environment variables by adding +arge. This will log command execution for all users.

If instead of all users you only want to audit a subset then use the /etc/security/audit_user file instead (or as well as to change the policy for some users), eg to audit just bob add "bob:ex:" to /etc/security/audit_user. The audit_user information can also be stored in all supported nameservices (files, NIS(YP), NIS+, LDAP) to provide a domain wide audit policy.

The audit trail produced by the kernel is passed to the userland auditd to write. Starting with Solaris 10 auditd uses plugins to write the trail (prior to Solaris 10 it always produced a binary audit trail file). The default is a binary trail but the data can also be sent over syslog in a summary XML-like format: see the audit_syslog(5) man page. A full XML format including DTD and XSTL can be produced out of the binary audit trail using the praudit(1M) command.

Finally the Solaris Audit system is included as part of the security target that helped get the Common Criteria certification of Solaris 10 (and several previous releases) to EAL4+ for CAPP, RBACPP, LSPP. I would not expect that the "auditing" in ksh93 would be sufficiently secure or detailed to met any Common Criteria audit requirements.

The Security Services admin guide has more information on the capabilities of Solaris Audit and information on administration as well as full details of the connect of the audit records.

Friday August 15, 2008

To be able to build the ON source tree for OpenSolaris you first need to setup some environment variables. There are two tools provided in the SUNWonbld package (usually installed in /opt/onbld/bin) that do this: ws(1) and bldenv(1). How do you pick which one to use ?

I used to use ws(1) a lot because it works well with partial Teamware workspaces, I changed a few years ago (see below for why). The reason it works well in that case is because it sets some additional environment variables to point include and library search paths into the workspace parent. ws(1) doesn't look at your nightly environment file it "works stuff out" based on your repository (Teamware or Mercurial).

For Mercurial that isn't likely to work since for most cases your parent is not available over NFS/local (or even if it theoretically is it could be slow). Also Mercurial doesn't support partial workspaces so you may as well have run at least 'dmake setup' in $SRC anyway. ws knows about this and won't try an setup those environment files if your default hg path is ssh:// http:// or https:// [ note we don't use http/https for ON not even on opensolaris.org ].

So how does this differ from bldenv(1) ?

bldenv(1) sets up the environment almost identically to nightly(1), it does so because it uses the same environment file. The main thing to know about bldenv(1) is that by default it sets up for a non-debug build, pass -d if you want a debug build. Like nightly(1), bldenv(1) supports MULTI_PROTO - both the debug and non debug proto areas existing at the same time. This is really useful because you can run nightly builds (full or incremental) but then build components locally as well and they will be built the same way and you can the interactively run makebfu(1) to get a new set of archives.

My personal recommendation is to use bldenv(1) but only after you have run at least one full build first.

Thursday August 14, 2008

First lets look at the normal POSIX file permissions and show who we are and what privileges our shell is running with:

# ls -l /tank/fs/hamlet.txt 
-rw-rw-rw-   1 root     root      211179 Aug 14 13:00 /tank/fs/hamlet.txt

# pcred $$
100618: e/r/suid=0  e/r/sgid=0
        groups: 0 1 2 3 4 5 6 7 8 9 12

# ppriv $$
100618: -zsh
flags = 
        E: all
        I: all
        P: all
        L: all

So we are running as root and have all privileges in our process and are passing all on to our children. We also own the file (and it is on a local ZFS filesystem not over NFS), and it is writable by us and our group, everyone in fact. So lets try and modify it:

# echo "SCRIBBLE" > /tank/fs/hamlet.txt 
zsh: not owner: /tank/fs/hamlet.txt

That didn't work lets try and delete it, but first check the permissions of the containing directory:

# ls -ld /tank/fs
drwxr-xr-x   2 root     root           3 Aug 14 13:00 /tank/fs

# rm /tank/fs/hamlet.txt
rm: /tank/fs/hamlet.txt: override protection 666 (yes/no)? y
rm: /tank/fs/hamlet.txt not removed: Not owner

That is very strange, so what is going on here ?

Before I started this I made the file immutable. That means that regardless of what privileges(5) the process has and what POSIX permissions or NFSv4/ZFS ACL it has we can't delete it change it nor can we even change the POSIX permissions or the ACL. So how did we do that ? Without good old friend chmod:

# chmod S+ci /tank/fs/hamlet.txt

# chmod chmod S+v immutable /tank/fs/hamlet.txt

See chmod(1) for more details. For those of you running OpenSolaris 2008.05 releases then you need to change the default PATH to have /usr/bin in front of /usr/gnu/bin or use the full path to /usr/bin/chmod. This is because these extensions are only part of the OpenSolaris chmod command not the GNU version. The same applies to my previous posting on the extended output from ls.

In "compact" form:

ls -V@ -/c -% all /tank/fs/hamlet.txt
-rw-r--r--+  1 root     root      211179 Aug 14 12:20 /tank/fs/hamlet.txt
                {AHRSa-i--u}
                timestamp: atime         Aug 14 12:37:37 2008 
                timestamp: ctime         Aug 14 12:32:58 2008 
                timestamp: mtime         Aug 14 12:20:08 2008 
                timestamp: crtime        Aug 14 12:19:41 2008 
                user:lp:r-------------:-------:deny
                 owner@:--x-----------:-------:deny
                 owner@:rw-p---A-W-Co-:-------:allow
                 group@:-wxp----------:-------:deny
                 group@:r-------------:-------:allow
              everyone@:-wxp---A-W-Co-:-------:deny
              everyone@:r-----a-R-c--s:-------:allow

In verbose form:

ls -v@ -/v -% all /tank/fs/hamlet.txt
-rw-r--r--+  1 root     root      211179 Aug 14 12:20 /tank/fs/hamlet.txt
                {archive,hidden,readonly,system,appendonly,nonodump,
                 immutable,noav_modified,noav_quarantined,nounlink}
                timestamp: atime         Aug 14 12:21:12 2008 
                timestamp: ctime         Aug 14 12:32:58 2008 
                timestamp: mtime         Aug 14 12:20:08 2008 
                timestamp: crtime        Aug 14 12:19:41 2008 
     0:user:lp:read_data:deny
     1:owner@:execute:deny
     2:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     3:group@:write_data/append_data/execute:deny
     4:group@:read_data:allow
     5:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     6:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

One interesting thing it doesn't tell me about this file is that it is that all that information is encrypted on disk. For that I have to use zfs(1):

# zfs get encryption tank/fs
NAME     PROPERTY    VALUE        SOURCE
tank/fs  encryption  on           local

Or a little more verbosely:

# zfs list -r -o name,encryption,keyscope,keystatus,mounted tank 
NAME           CRYPT  KEYSCOPE    KEYSTATUS  MOUNTED
tank             off      pool    undefined      yes
tank/fs           on      pool    available      yes

I wonder if it is worth having the verbose ls(1) output indicate that the file was encrypted on "disk" by the filesystem.

What would people do with that info if they had it ? Any ideas let me know.

Tuesday August 12, 2008

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 July 25, 2008

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 July 24, 2008

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 June 26, 2008

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".

Allowing role to same role over network

The current implementation of pam_roles has an "allow_remote" module argument that allows the role to be assumed over the network when PAM_AUSER is set. Currently only ssh with hostbased user authentication sets PAM_AUSER.

It also only allows user to role not role to (same) role. However I believe that "role to (same) role" is actually much more useful. Consider the following example case:

Helpdesk users login on a workstation/Sun Ray or something not even running Solaris. They ssh (using any userauth method) to some "Trusted Host". This "Trusted Host" then has network routes to the production machines. It is also possible that "Trusted Host" has some stronger initial user auth (eg, OTP or SecurID).

The helpdesk user assumes a role on "Trusted Host" (this is audited on Trusted Host, maybe also has additional PAM modules to determine when roles can be assumed).

The user (now with ruid of the role) then uses ssh to connect to the appropriate production host as the role.

If no auditing is in use the user doesn't even need to be known on the production host at all just the roles. Even if the user is known they don't need to be allowed to login (eg using pam_list).

This is a reasonably common and in my opinion very sensible architecture. I've heard of this existing at several sites.

This can actually be achieved today by manually editing a roles user_attr(4) entry so that it has a "roles=" entry for itself eg:

	sysadm::::type=role;roles=sysadm;profiles=System Admin

However this can't be done using the rolemod(1M) or other admin tools since they currently believe that roles can't have roles.

A fix for this could be integrated into pam_roles so that "allow_remote" allows PAM_AUSER to be the role as well. However this now means that all roles can be remotely assumed by themselves. In my opinion that isn't any weaker a policy than what allow_remote already means.

It also makes sense to me that a role be allowed to "su - rolename" to itself - this has no audit impact but has the advantage of being a nice easy way to "clean" the environment. To allow that roles would need to be able to assume themselves regardless of the value of "allow_remote".

Allowing roles to have roles

In the general case, why can't a role have roles ?

I see no reason why not, in fact I can thing of many cases where allowing roles to have roles actually helps build a more understandable and usable policy.

Continuing with our helpdesk scenario above.

A slightly different implementation is that the user assumes the "helpdesk" role on their workstation and runs tools as helpdesk. Some of those tools need to remotely access production machines. However the users don't have accounts that can login on those remote machines. The only accounts that can login on the production machines are those that represent roles eg "dbadmin" and the "helpdesk" account.

In this case the "dbadmin" role is given to the "helpdesk" shared account as well as some of the core database team.

For this to work we need to allow roles (helpdesk) to have other roles (dbadmin).

Again I think this is a perfectly reasonable deployment case, and one that is already in use without roles. By making helpdesk and dbadmin roles we can increase the security. If we stick with the current "roles don't have roles" then we weaken the security because now one or both of the "helpdesk" and "dbadmin" would be deployed as normal user accounts.

Like above this is actually already possible by manually updating the user_attr(4) entries for the roles, eg

	helpdesk::::type=role;roles=dbadmin
	dbadmin::::type=role;

To make this part of the proposal "official" requires updating the administrative interfaces. pam_roles doesn't need to be changed at all.

( Jun 26 2008, 11:41:45 AM BST ) Permalink

Friday May 23, 2008

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> 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>end
$ pfexec svcadm restart gdm

Friday May 09, 2008

Seems like for some reason I didn't actually post this when I wrote it on Jan 10th 2008, so I'll post it now

I've just read over the PC World "10 Worst Keyboards of all time" article. Out of the 10 there was only 3 I hadn't actually used (the IBM PCjr, the original PET, and the Atari 400. All the others I've actually used at least once. I found it interesting on the selection of the Sinclair keyboards, the ZX Spectrum one suffered all the same problems as the Timex 1000 but the metal "cover" also came off over time. I replaced the key membrane on my speccy at least once and upgraded the heat sink to try and stop it failing again (didn't really help in the long run)).

My current vote for the worst keyboard of all time is actually the iPhone/iTouch - yes it doesn't have a real keyboard but an on screen touch one instead, and the later lacks Bluetooth for connection of a "real" keyboard. I don't own an iPhone/iTouch just played with friends so maybe it gets better over time.

My favourite keyboard - Sun Microsystems Type 7 (USB) US UNIX layout. The layout is critical despite being a Brit I hate the UK keyboard layout with a passion it sucks for writing C or shell code because " and # get moved! The UNIX layout is also important so that Control is on the same row as return - caps lock has no use since I stopped writting COBOL code.

My current home machine is a first generation (ordered the day after the announcement) PPC Mac Mini. I initially ordered it with 512Mb RAM and no WiFi or Bluetooth. It has since been upgraded to 1G (the max this machine can take) and had the WiFi/Bluetooth added (and it now lives in the UK rather than California where it was bought). When I first bought it it was as a secondary machine to learn where MacOS was, I hadn't used MacOS since System 7 at that time. It soon became my our primary home desktop and got given gifts of a (wired) Mac keyboard and 20" Cinema screen in addition to its upgraded memory and wireless capabilities.

It has been serving us well but I feel like a new machine. While I love OpenSolaris and spend a huge number of hours developing for it and using it MacOS is what I want to continue using for my personal stuff for now (I like iTunes, iPhoto, Safari and more importantly so does my wife). So if the current PPC Mac Mini is to be repurposed it needs to be Apple hardware.

I titled this "Missing Apple Mac hardware", why ? I can't find a non laptop Mac that actually fits what I want in terms of computing resources and cost. Disk space isn't an issue I'd buy the machine in the lowest possible disk configuration because all my data is stored on a ZFS on a separate system running OpenSolaris and mounted on the Mac using NFS.

The best CPU/RAM combination I get buy on a current Intel Mac Mini is 2GHz and 2G RAM for £558. The next option is a Mac Pro and that starts at a wallet breaking £1,749, it is a nice workstation but out of budget for my desktop machine. There is Mac hardware in between that price range but with, for me, a fundamental problem because it has an integrated LCD and comes with a keyboard. Now integrated systems are great I remember fondly using the Sun ELC workstations at University and my current Sun machine at home (and the office) is a Sun Ray 270 (ultra thin client with integrated LCD). However I like my 20" Apple Cinema display and I want to keep using and it doesn't need to be replaced, same for the keyboard/mouse.

The Apple Mac I want to buy would have a CPU around 2.4 to 3GHz and 4G RAM, a single disk and a reasonable graphics card - this isn't a games machine (I use consoles or my phone for games these days) - for helping with photo processing. Of course it should be "green" in that it should allow me to reuse my existing LCD monitor and keyboard (both Apple products!). Pretty much something like a Sun Ultra 20M2but capable of legally running MacOS X 10.5 and for about that price

So Apple where is my missing Mac ?

Update: I know I can do dual monitor on with an iMac (first saw that on a mono SE30 with an external colour display and putting windows "across" the boundary it was done perfectly!) but I already have two monitors on the desk (the Sun Ray 270 mentioned above) and I don't really have space for another one. The big issue with the top end Mac Mini is the memory only goes to 2G according to Apple and some of that will be taken away by the Intel GMA graphics. One of the reasons I need at least 4G RAM is that there is always two users logged in (with fast user switching) to this machine. A bit of space to upgrade beyond 4G of RAM would be nice.

Wednesday April 30, 2008

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

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

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.

search

recent entries

• ZFS Crypto Codereview starts today
• Using the Mercurial Forest extension for OpenSolaris onnv-gate
• Auditing shell commands
• OpenSolaris ON development: Picking ws(1) vs bldenv(1).
• Making files on ZFS Immutable (even by root!)
• Heaps of info available on files via good old ls(1) [ But not encryption status ]
• What is the maximum password length for Solaris/OpenSolaris ?
• T5120 donated to Haskell Community
• Enabling OpenSolaris Auditing without Device Allocation
• A TX window without a label ? Opps ?

navigation

links

rss feeds