9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: presotto@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] possible way to have the secstore on the cpu server
Date: Mon, 17 Jun 2002 07:51:16 -0400	[thread overview]
Message-ID: <b824b50e8f53c4d11362f79ca96e9111@plan9.bell-labs.com> (raw)

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

             reply	other threads:[~2002-06-17 11:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-17 11:51 presotto [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-06-17 10:25 nigel
2002-06-15 15:34 presotto
2002-06-15 15:32 presotto
2002-06-15 14:02 nigel
2002-06-14 16:42 Russ Cox
2002-06-14  8:26 nigel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b824b50e8f53c4d11362f79ca96e9111@plan9.bell-labs.com \
    --to=presotto@plan9.bell-labs.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).