Grant permission to manage another users processes

Unless you give userC access to userA and userB's accounts, there's no way to do it without using something like sudo that grants special permission. There's no facility in the Linux kernel to grant access to processes based on groups or access control lists.

But you shouldn't fear using sudo. You can configure it to allow only specific commands and only allow the commands to be run as specific users. I.e. you can allow just userA and userB's process to be killed by userC, but not allow userC to kill other processes.

You could make a second application that can kill processes for example process-proxy, you can run that as root only once (maybe make it start automatically at boot) and leave it listening to for a Dbus message, or some other mean of communication. Finally a client application, for example send-message to send the messages and can be run at will by userC.

userC@server $ ./send-message -kill -pid 30889
userC@server $ ./send-message -nice 2 -pid 30889

In other words make a proxy application. You just need to make sure it only listens for messages from userC, and also may be a good idea to only let it kill specific processes for specific users.

P.D. Dbus may not be the best Idea (I'm not fully familiar with it) but there are plenty of ways to make process-proxy aware of a message. For example, monitor for a file on certain folder (for which only userC and root have access for security) that can contain the pid of the process we need it to kill.

This is similar to Martin’s answer, but (arguably) a bit simpler.  Write a new version of the kill command that looks something like this:

If (current UID (i.e., invoker’s UID) != userC)
        exit (with an appropriate error message)
parse args
call kill() system function

If you’d rather not rewrite the kill command, write your program to exec /bin/kill with whatever arguments were passed to it.  Compile, test, and then make two copies: one that’s setUID to userA and one that’s setUID to userB.  For extra safety, put them in a directory that only userC has access to.

If making life easy for userC is a paramount concern, write a front-end program that determines whose process(es) userC is trying to ‘kill’ and invokes the appropriate copy of the first program.  Or it could run both copies.

This is, essentially, writing your own stripped-down version of sudo, so I don’t know whether it will be acceptable to you.  You said that you want to “do this without relying on sudo access”, and, strictly speaking, with this answer, you wouldn’t be relying on anything –– you would have complete control over the configuration of the solution.