From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] secstore Message-ID: <20020515150928.P1584@cackle.proxima.alt.za> References: <32d3c05b625f12fdd78d72e5fbcc698f@plan9.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <32d3c05b625f12fdd78d72e5fbcc698f@plan9.bell-labs.com>; from presotto@plan9.bell-labs.com on Wed, May 15, 2002 at 08:33:41AM -0400 Date: Wed, 15 May 2002 15:09:29 +0200 Topicbox-Message-UUID: 92aa5a04-eaca-11e9-9e20-41e7f4b1d025 On Wed, May 15, 2002 at 08:33:41AM -0400, presotto@plan9.bell-labs.com wrote: > > To answer lucio, it's not a matter of obscurity. You > just don't want the files on a shared file server . If > it gets backed up, then a mistake of permissions on the file > can last forever in the dump and not be noticed except by > attackers. > Yes, Nigel brought that up. I think it is critical not to record the keys on any medium other than for use. Again, reality interferese here, or at least human fallibility. I keep wondering what would happen if I had a fatal accident and my client needed to access hardware to which I alone hold the root password :-( In fact, the main attraction of Plan 9 4ed is very much its authentication service (and Venti, hopefully soon), at least to me. > Whether or not you let others cpu or rx to the machine which is > the auth server is a separable question. > Well, one has to measure security from the wrong end, so the fewer opportunities for intrusions, the better. > This still leaves the auth server open to trojan horses and > the like. I'ld be happier with a standalone auth server that > noone can log onto except for a select few. There are less My fascist instincts suggests this has to be the recommended route. Each alternative has a risk attached to it and the administrator must be aware of it. The problem, off the cuff, that I see is that you can't plug holes in security if you move from the prescribed, you can just hope they aren't exploited - you may be able to monitor, but that becomes a new burden. > mistakes you can make that compromise security. Of course, > we don't even do that. Our auth server is also our console > server so that everyone that needs console access logs on. Punishment also helps :-) But an ounce of prevention and all that... ++L PS: Bell Labs are privileged to have "sophisticated" users, both intellectually and, at least apparently, in a social/communal sense. It is hard to remember from that perspective that the enemy outside the Labs lurks in every corner. I'm pleased Nigel asked the question because I would not have spotted the need for additional care. PPS: I don't quite understand the concept of a "console" server, what is it actually used for? Management of headless hosts such as FSs?