Went ahead and implemented this, works as required. I had to change one thing, in the Navigate model, to use the model's auth-manager to check security, rather than Navigate's auth-manager (which is set to nullauth). CreateDB is now secured, but it still shows up in the Keel menu when not logged in, or when someone other than root is logged in. The reason is that we use the hint "createdb-seq" in the menu, so Navigate ends up checking auth. for Sequence and not CreateDB. I think, for now, the simple work around of preventing the display by group works just fine. In the future, we might create a special auth-manager for Sequence that actually checks the auth for the model pointed to by the current step.
In summary, two steps to protect and hide CreateDB. After running CreatedDB initially from the Keel menu, delete the am="nullauth" from the createdb model's config and restart Keel. This will prevent anybody but root from running createdb. It will still show up in the Keel menu as an option, though. To prevent that, the menu entry needs to be protected in the config to display for root only.
Shash
Michael Nash JGlobal.com wrote:
Shash:
Of course - that makes much sense, and is even easier. Great idea!
Mike
On Fri, 24 Oct 2003 18:06:02 -0500 "Sasvata (Shash) Chatterjee" <[EMAIL PROTECTED]> wrote:
Mike and Steve,
I think we can take care of this pretty cleanly using existing Keel capability. Currently createdb does not implement Securable. We can change that, and simply put am=nullauth for createdb. As Mike has said, it doesn't do anything harmful, even if run by "unauthorized" users. But if one was concerned with it, after running createdb the initial time, the am attribute could be changed to defaultauth, and createdb will be secured.
Shash
http://keelframework.org/documentationI did not know what its behaviour was in regards to alreday existing tables. If it does not clobber, than not a bad thing. I wonder if an appropriate "lockdown" would be to rig it so that it can only be run from localhost?Given ASP use of Keel apps (e.g. BahamasCommerce!) that wouldn't work well for me personally. Sometimes I don't visit the server for quite a long time in person :-)
And/or require the system root password as a parameter? I am thinking about what would happen if some kid tried it for a lark.Essentially it would do nothing, assuming all tables are already there. The only downside would be that if you deleted/dropped some tables it would just put them back again. Ditto with default records in tables - if there's already a record with that key, it does nothing, so it won't do anything nasty like set all your passwords back to default. I suppose it's a risk for a DOS attack, essentially, but not much else.
I'm experimenting with configuring models to require SSL, and in addition to that can require some models to use client-side certif SSL, which might be one way to go. That way there's no way to run dbcreate unless you have a certain client-side certificate - although I wouldn't do it this way by default. The other way to do it would be to simply remove the config for createdb from system.xconf once you've created the tables - then it can't be run by anyone.
Just some thoughts - these issues could apply to many models, I suppose.
Mike
Regards, Steve
Michael Nash JGlobal.com wrote:
Steve:
Good idea to lock the model down, but we'll still need some way to run it as a special exception if you're logging in via the svc-authentication/authorization-persist. Of course, we could use a combo of svc-authentication-config and svc-authentication-persist, that way a basic username for createdb could be right in the configuration.
OTOH, running createdb is pretty harmless, actually - it never deletes anything, only creates it if it isn't there, so it's not the worst in terms of security problems.
Mike
Keelgroup mailing list
[EMAIL PROTECTED]
http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
Michael Nash
JGlobal Ltd. http://www.jglobal.com
Bahamas Commerce and Trade http://www.bahamascommerce.com
http://keelframework.org/documentation
Keelgroup mailing list
[EMAIL PROTECTED]
http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
http://keelframework.org/documentation Keelgroup mailing list [EMAIL PROTECTED] http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
