Tuesday November 29, 2005

Setting the time and date in Solaris from a non-global Zone

I was presented with a question a while back. Is there a way to have a non-global zone set the time and date of a Solaris 10 system? The answer I came it with is "Sort of." Here's why:

I looked at setting up an RBAC profile assiging the command /usr/bin/rdate, with uid=0 and privs=sys_time, but that didn't work. There is no way to assign an RBAC profile from a global zone to a user from a non-global zone, and there is no way to assign an RBAC profile directly to a zone. (That's a neat idea, though, isn't it?)

Then I thought about using an ssh key to permit passphrase-less authentication from a user in the non-global zone, to the global zone to log in and run a command (set up in an RBAC profile) to allow them to set the date. Here's my solution to this problem:

First, I create the proxy user, and then I set up the RBAC profile in the global zone:

1. Create the user account (I use proxy, because I also use this account for other purposes):

2. Add this line to /etc/security/prof_attr:
Proxy:::Special Proxy Profile:

3. Add this line to /etc/user_attr:
proxy::::type=normal;profiles=Proxy

4. Add this line to /etc/security/exec_attr:
Proxy:solaris:cmd:::/usr/bin/rdate:uid=0;privs=sys_time

Now, if you were to su to proxy and run rdate 192.43.244.18 you would effect a setting of the time and date on your system, hopefully without errors.

Now, to set up the access from the non-global zone, `su` to the proxy user account, and generate an ssh-key. I'm using a commented, 1024-bit Diffie-Hellman key, just for example purposes. Yours can be whatever bit-level and algorithm you prefer.

Once the key, is generated, copy the contents of your public key file to your authorized_keys file:

Now edit the .ssh/authorized_keys file and change:

So that it looks like this:

As root, in the global zone, lets apply a restrictive shell, and limit the PATH with a profile that's owned by root (this helps limit destructive potential, if someone were to try to use the passphrase-less ssh-key for no good:

Play around with an rbash shell, and you'll see that commands are restricted to what's in the path, and you can't have a '/' in any commands to be run.

Now, you could use a script like Brendan Gregg's zcp to copy files from the global zone to the non-global zone, but sometimes if it's just a little file like this, I'll just go ahead an copy it to the non-global zone's TMP directory.

Now, let's log into the zone, and setup a script that can set the date and time
for the whole system.

So there you are. A simple command you can run in a non-global zone, to set the date and time for the entire system, which until zones support a separate clock from the global, is as best you can get. (Timezone's not included)

However, you're not really setting the time in the non-global zone, you're causing a process to log into the global zone and set the time there.

If you're primary concern is an application that runs in a zone, that needs permission to set the time/date, then this should work for you, as long as you don't have any objections to using ssh keys this way, from a philosophical or security-minded point of view.

So, really:
Q: Can you set the time and date from a non-global zone?
A: No. but you can automate setting it in the global zone, from a non-global zone.

If you're behind a firewall that doesn't allow access to anywhere on port 37, and thus your Global zone also cannot set the time and date from a Time Server, then you'll need to set up some kind of dynamic ssh tunnel to ssh one step further out, and tunnel that rdate command through that ssh tunnel.

I'll cover that in another post.