CAcert System Admins discussion list

[Sam Johnston <samj AT samj.net>]

On Wed, Mar 25, 2009 at 11:22 PM, Mendel Mobach <cacert AT leercoden.nl> wrote:

On Mar 25, 2009, at 10:55 PM, Sam Johnston wrote:

Mendel,

If this is your proposal for a secure syslog server then I would suggest that function be kept on entirely separate bare metal hardware.

Yes, I would suggest that one too in the future, but for a first start for the syslog server it would be more-secure than no syslog server at all. (Which we do have now.).

I'm surprised you would present this argument after I just finished explaining why it is bogus, but if we can't have a dedicated box because we don't have the hardware then that's a different issue.

The syslog server is nice add-on for the moment, the main is the first domU. This is for several reasons I will explain, but not now on a public mailinglist.

Security by obscurity? You're going to need either a policy exception or an arbitration to conceal anything from public view so you'll want to think about what is and is not really secret.
 

Vservers are sufficiently secure for the purposes we have been discussing and the maintainability is great (one set of mounts for all systems, not one for each, for example).

Depends, only if all the vservers run the same kind of software, which will be going to be a problem.

As critical sysadmin and responsible for a secure network with secure machines in Ede (no, I'm not the only one, it's a team and I did discuss this one of course with the team first):

I would like to keep a secure network and preferably more secure than it's at the moment. Secondly I really do like the idea of security updates. Security updates at the moment mean that we have to take down all the vservers at once on one of the boxes just because we need to update a vserver 'hosting server'. If we want a less interrupted[1] service we preferably move to another kind of setup where we can 'move' the servers in a easy way without much downtime (or none at all) while still being able to update bioses (those things do contain bugs too, are risky[2]) and giving the admins of the non-critical servers some form of freedom[3].

[1]: Read: more updated
[2]: If it fails the whole machine won't come up! So won't the vservers.
[3]: Completely depends on the situation of course.

Downtime for updates is tolerable, insecure systems is not.
 
At the end of the day I don't really care *how* you guys deliver the service, so long as the organisation is able to function. I've been waiting over a year now for functions I need for OA and I would suggest that vservers could in fact save us a lot of time.

I would also suggest that something simple and elegant be created as it will be subject to peer review (e.g. talks at conferences and the like). Your solution sounds secure but complicated.

Sam