RigidBody is usually the right choice for interactive objects, unless it is a puzzle game that needs perfect accuracy (like you are sliding on a grid and can't move off it, etc.). KinematicBody is meant for players and enemies, that are controller either by a user or by AI. They can affect the physics in the game, but are not intended to be affect by physics (e.g. gravity is not applied) though their movement can be stopped by a StaticBody. Honestly, it may be a good idea to try to solve the issue you are having with RigidBody, rather than reinvent the wheel.
However, there some possible options you have. When you call move_and_slide() on the player, there will be KinematicCollision object detected. You can get this collision by calling get_last_slide_collision().
From there, you can check if the collider is the object you are looking for, and then apply movement to it, using the paramters of the KinematicCollision (such as collider_velocity or normal). In practice, though, I don't think it will work well. Since what if the box hits a wall? Then the box will stop (due to the physic engine) but the player won't. So you have to have two-way collision between the box and the player (or multiple boxes, multiple walls, etc.) to the point where I think it will just jitter and eventually fail.
The other option would be to use a RigidBody for the box, but override the function _integrate_forces(). This gives you the full physics state of the object, and you can do anything you want it it. You can make it move faster or slower, pause time, restrict to certain axes, etc. This is still sort of a hack, but at least it will work with the existing physics engine.
However, I still think it best to make sure you have explored all the options and parameters in the editor, to get the physics working before you try any sort of custom hack type of code.