Home
The Toolkit for Online Communities
16684 Community Members, 1 member online, 2289 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Q&A : RFC: Security policy for OpenACS (Security hole in OpenACS 5.1!) : One Message

Forum OpenACS Q&A: Re: RFC: Security policy for OpenACS (Security hole in OpenACS 5.1!)

The problem with post is if you get redirected thru /register because you session expires the update will break. That might be a feature. It also means you can't have links that perform admin type actions. Again that may be a feature.

The more I think about it the more I think sudo is the answer because it solves the real problem which is you don't want to run as root all the time. If I'm paranoid I could authenticate on every admin action without changing code. If I want to run as root all the time on my dev box that's ok too.

I looked at the code a bit and I think all you would need to do call sudo::checkauth in the request processor just before the other permission checks. If it's been too long since you authenticated redirect to reauthenticate and set a cookie that's a database key to the time.

You would also need a tcl interface so on package installs you could set defaults

If each entry in the sudo table is an object you could have even more control. For example I could create a /manage directory under a package and control access just like /admin

Yeah, the real problem isn't 'run(ning) as root all the time', I'm not sure what that even means. But whatever someone can do because of a vulnerability isn't the problem, just the potential effect of not fixing the problem.

The problem is with the protocol which allows actions to be performed without the user's knowledge. But OpenACS can be fixed to make the vulnerability mostly go away. OpenACS cannot be 'fixed' to prevent an admin from installing a package which does whatever they want it to do. This is a feature, and it can't be prevented.