Re: [9fans] possible way to have the secstore on the cpu server

Re: [9fans] possible way to have the secstore on the cpu server

[nigel]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

At the point factotum starts on the cpu server, there is no secstore
service running, because cpurc has not yet run to start it.

Thus, in cpurc, after I have started the secstore service, I want to do

auth/secstore -G factotum | read -m >/mnt/factotum/ctl

to load the secstore into the already running factotum. This will prompt
for the secstore password, which is a pain if I want to reboot the cpu
server remote.

So, I grafted the nvram key loading code from factotum into secstore
under the option -N. The relevant bit of cpurc is:

	dossrv
	@{
		rfork n
		mount -c /srv/dos /n/9fat /dev/sdC0/9fat
		bind /n/9fat/secstore /adm/secstore
		auth/secstored
		echo secstored running
		auth/secstore -N -G factotum | read -m >/mnt/factotum/ctl
		echo keys loaded
	}

Now if there is a clever way to get factotum to reload itself from
secstore I would use that, but I don't think there is.

[-- Attachment #2: Type: message/rfc822, Size: 3353 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 142 bytes --]

Also, I'm confused.  Factotum already did read the nvram key, we
rely on it here for exactly what you use if for.  What did you have
to add?

[-- Attachment #2.1.2: Type: message/rfc822, Size: 1666 bytes --]

From: nigel@9fs.org
To: 9fans@cse.psu.edu
Subject: Re: [9fans] possible way to have the secstore on the cpu server
Date: Sat, 15 Jun 2002 15:02:51 +0100
Message-ID: <0538a1a8b42ab0f0bb459fc5e0ed97a9@9fs.org>

Good points all. Presotto had said a dictionary attack was possible if
the service ran on the cpu server and I can't see it.

Anyhow I've implemented it all, and perhaps will drop it all in the wiki
at some point.

One addition is a mod to secstore so it reads the nvram key rather than
prompting for one. This allows cpurc to load the cpu servers's factotum
with extra keys like the SSL ones.

Secstore is cool; it takes my mind off the awful VGA support.

Re: [9fans] possible way to have the secstore on the cpu server

[presotto]

[-- Attachment #1: Type: text/plain, Size: 143 bytes --]

Thanks, I understand now.  I think its time to add a ctl to factotum.
It already has all the code the read secstore so its easy enough
to do.

[-- Attachment #2: Type: message/rfc822, Size: 5800 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 917 bytes --]

At the point factotum starts on the cpu server, there is no secstore
service running, because cpurc has not yet run to start it.

Thus, in cpurc, after I have started the secstore service, I want to do

auth/secstore -G factotum | read -m >/mnt/factotum/ctl

to load the secstore into the already running factotum. This will prompt
for the secstore password, which is a pain if I want to reboot the cpu
server remote.

So, I grafted the nvram key loading code from factotum into secstore
under the option -N. The relevant bit of cpurc is:

	dossrv
	@{
		rfork n
		mount -c /srv/dos /n/9fat /dev/sdC0/9fat
		bind /n/9fat/secstore /adm/secstore
		auth/secstored
		echo secstored running
		auth/secstore -N -G factotum | read -m >/mnt/factotum/ctl
		echo keys loaded
	}

Now if there is a clever way to get factotum to reload itself from
secstore I would use that, but I don't think there is.

[-- Attachment #2.1.2: Type: message/rfc822, Size: 3353 bytes --]

[-- Attachment #2.1.2.1.1: Type: text/plain, Size: 142 bytes --]

Also, I'm confused.  Factotum already did read the nvram key, we
rely on it here for exactly what you use if for.  What did you have
to add?

[-- Attachment #2.1.2.1.2: Type: message/rfc822, Size: 1666 bytes --]

From: nigel@9fs.org
To: 9fans@cse.psu.edu
Subject: Re: [9fans] possible way to have the secstore on the cpu server
Date: Sat, 15 Jun 2002 15:02:51 +0100
Message-ID: <0538a1a8b42ab0f0bb459fc5e0ed97a9@9fs.org>

Good points all. Presotto had said a dictionary attack was possible if
the service ran on the cpu server and I can't see it.

Anyhow I've implemented it all, and perhaps will drop it all in the wiki
at some point.

One addition is a mod to secstore so it reads the nvram key rather than
prompting for one. This allows cpurc to load the cpu servers's factotum
with extra keys like the SSL ones.

Secstore is cool; it takes my mind off the awful VGA support.

Re: [9fans] possible way to have the secstore on the cpu server

[presotto]

[-- Attachment #1: Type: text/plain, Size: 142 bytes --]

Also, I'm confused.  Factotum already did read the nvram key, we
rely on it here for exactly what you use if for.  What did you have
to add?

[-- Attachment #2: Type: message/rfc822, Size: 1666 bytes --]

From: nigel@9fs.org
To: 9fans@cse.psu.edu
Subject: Re: [9fans] possible way to have the secstore on the cpu server
Date: Sat, 15 Jun 2002 15:02:51 +0100
Message-ID: <0538a1a8b42ab0f0bb459fc5e0ed97a9@9fs.org>

Good points all. Presotto had said a dictionary attack was possible if
the service ran on the cpu server and I can't see it.

Anyhow I've implemented it all, and perhaps will drop it all in the wiki
at some point.

One addition is a mod to secstore so it reads the nvram key rather than
prompting for one. This allows cpurc to load the cpu servers's factotum
with extra keys like the SSL ones.

Secstore is cool; it takes my mind off the awful VGA support.

Re: [9fans] possible way to have the secstore on the cpu server

[presotto]

What I was, and still am worried about, is accidentally letting
the secstore files be read.  The only thing that protects against
a dictionary attack now is the service cutting you off for 5 minutes
or so after a small number of failed attempts.  Accidents are
too easy in an environment that has varied and changing services
like a cpu server.  It's quite likely that some typo will make
the secstore files readable to a bad guy for some window.  Anyone
that can read them can mount a dictionary attack, all you need
guess is the user's password.  What's in the secstore files
is a uses' crown jewels, so to speak.

Re: [9fans] possible way to have the secstore on the cpu server

[nigel]

Good points all. Presotto had said a dictionary attack was possible if
the service ran on the cpu server and I can't see it.

Anyhow I've implemented it all, and perhaps will drop it all in the wiki
at some point.

One addition is a mod to secstore so it reads the nvram key rather than
prompting for one. This allows cpurc to load the cpu servers's factotum
with extra keys like the SSL ones.

Secstore is cool; it takes my mind off the awful VGA support.

Re: [9fans] possible way to have the secstore on the cpu server

[Russ Cox]

You could use kfs and make the files only
bootes-readable.  It doesn't matter that the
service file is world-rw -- once it gets mounted
the kernel is enforcing the appropriate attach
names.

You could run your own little dossrv.

They don't really need to be noswap,
since if you can read the swap disk after the pages
get swapped out, then you could just read the
disk containing the actual files.

Arguably you don't need to be private either,
since if you can debug the process you can
read the underlying disk.

Russ

[9fans] possible way to have the secstore on the cpu server

[nigel]

It seems possible to store the secstore on the cpu server, without the
files being accessible to someone (other than bootes).

The attacker cannot open anything in '#'S as it is owned by bootes.  I
had assumed before that '#'S is generally readable, but it's only
group/user readable.  The service created by kfs is other r/w, so
obviously kfs would be a bad choice.  But, /srv/dos is accessible by
user only, so a small dos filesystem would appear to be unmountable by
anyone other than bootes.

The dossrv would have to be noswap and private, which given the amount
of memory it consumes might be the biggest impediment.

I realise that a separate auth server with no cpu service is
intrinsically more secure, but does the above have any fatal flaws?