Re: Perl->PHP Object Security

[Jason Pincin <chardros@linuxkb.org>]

Here's some more thoughts and some things I didn't touch on.

In order for these Perl script to operate fully under the current security
model, they cannot change the DB at all themselves.  All modifications
would have to go through the php-gateway.  They could however perform
queries and provide information without going through php.  So long as
they are not returning user info or anything like that :).  Which they are
not... Aaron is coding this app to only return info on Object Types 1, 3,
5, and 7.  KB-Root, KB-Containers, Applications, and External Links
respectively.

The other option for authentication is to allow Perl to pass the object ID
of the user performing the opperation, or in other words, the object ID of
the user the opperation is ATTEMPTING to perform under... and securly
passing the password along with that.  Then PHP can do the auth.

Don't know how we'd secure the password passing.  Perhaps fire off a
single apache process that only answers to localhost or yukon?  Thoughts?

-- 
Jason Pincin
Linux Knowledge Base Project Leader (http://www.linuxkb.org)
http://vodka.linuxkb.org/~chardros


On Thu, Jan 20, 2000 at 11:30:39AM -0500, Jason Pincin wrote:
> This email is primarily directed at Aaron, but I encourage everyone to
> read into it - examples of what others are doing is a great way to
> increase our own understanding :).  I'll give a brief summary of what
> we're doing here.
> 
> Summary:
> As of my last major functions.php3 commit, the site has taken on a new
> security model.  All permissions are tracked by 3 things.  The object they
> are granted TO (normally a user object - or user container), the object
> they are giving permissions ON, and the action or actions being granted on
> that object.  Without going too far into it, this gives the site a VERY
> flexible security model that we won't even begin to tap soon.  Now - this
> is fine and dandy for people writing pages in php.  All the functions for
> usage of the system are in place, and permission checking is pretty much
> auto-magic with the aid of render.php3.
> 
> Problem is, Aaron is investing a LOT of time into an excellent application
> that will give us another way of managing categories and external content.
> His question to me last night on IRC was: how are his perl scripts going
> to interface with php object security.  Excellent question.  First, I'm
> working on a page that will allow Aaron to make php function calls from
> his perl scripts via apache, and return codes, etc.  Now that everyone has
> a background, I'll begin the discussion - everyone should be able to
> follow along... and feel free to chime in if you have any questions,
> comments, or suggestions.
> 
> Now.
> 
> Here's the biggest problem I see.  The php object security relies heavily
> on http-auth to set $current_user.  Anytime anyone performs an action,
> $current_user is tested to insure they have the proper permissions to
> perform that action.  My PHP code assumes current user is correct, because
> render.php3 will only set $current_user to a non-anonymous user given a
> succesful http-authorization.  
> 
> Now - if Perl script want to operate under this security model through the
> php-function gateway I'm creating, the gateway php script needs to set
> $current_user.  For this to happen, we need a reliable and secure way for
> Perl to pass the current user objectID along with the function/action
> being done into the php gateway script.  This HAS to be secure.  People
> cannot be able to falsify this passage or anything... because my php code
> is just going to ASSUME it's coming from a secure source... as it does
> with http-auth.  If you pass me in the object IDthat translates to "god"
> who can do ANYTHING, then the php scripot will allow you to delete
> KB-Root.  Not a good thing.  So now, you'll have to tell me how you'll
> verify the user, and how you'll pass that ID to the php gateway script.
> 
> Thoughts Aaron?  Anybody?
> 
> -- 
> Jason Pincin
> Linux Knowledge Base Project Leader (http://www.linuxkb.org)
> http://vodka.linuxkb.org/~chardros