Date: Sun, 19 Mar 1995 13:23:51 -0800 From: jkh@violet.berkeley.edu (Jordan K. Hubbard) To: Nik.Clayton@brunel.ac.uk Cc: security@FreeBSD.org Subject: Re: FreeBSD and security Message-ID: <199503192123.NAA23182@violet.berkeley.edu> In-Reply-To: <3k9iei$g3a@beable.brunel.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
What really needs to happen is that somebody needs to go write a daemon program that just sits listening for requests and fully authenticates users (admins) that want to schedule things for execution and/or pick up the results of previous "security" runs, and the like. I would base such a daemon VERY strongly on TCL. It's actually all pretty simple. You implement the daemon as 3 separate subsystems: Authentication Script engine Database The authentication system is responsible for establishing connections with clients and authenticating requests for information (or controlling the daemon). If you feel the need, you can even encrypt connections to avoid anyone spying on your security procedures (since you're going to be throwing raw tcl code at this thing at the higher priv levels, it's not such a bad idea!). The script engine is your specially configured tcl interpreter, e.g. some variant on secure-tcl where you have a LARGE body of nice canned commands that also have level classifications in a privilege ring scheme so that you've at least some ability to classify security tasks at different levels for administrative personnel with different levels of privilege. You also add a couple of extra features like checkpointed interruption and loop detection and you've got a pretty able little security language that is also reasonably hard to break (this is important unless you also plan on making this baby multi-threaded!). TCLs basic looping and conditional constructs are more than able enough that you can build a pretty reasonably little library of primitives for checking user attributes, file permissions, network states, filesystem statuses and whatnot and string 'em together for pretty much any kind of system administration task. Your primitives emit database log records as appropriate, and you can come back and query the system later to see what the "state" of it was on a given time and date (the very best of security typically being that which is exercised *after* a break-in, utilising good log information). The final part, the database, would collect log records and associated other information produced by the various primitives in the script engine (or individual scripts themselves - I'd expose the database API into TCL too, of course! :-) for later collection. You'd do the database API such that the database(s) could reside on some other machine, of course, allowing you to keep multiple copies of the log information on one or more remote central servers. I saw a database at CeBIT (db++ or some such name) which looked like it might be quite capable for something like this - it's even got the call-from-TCL ability already included. Anyway, yeah, so.. You could do a pretty nice central security management system this way.. Write a GUI management station based on TK or something and really go to town! :) Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503192123.NAA23182>