4

So this is a description of the system I'm working on :

  • a "manager" process spawns all the other applications.
  • The manager application runs as root user.
  • so now, any process that it spawns also inherit root user privileges.

The third point is clearly makes my application (let's call it 'player') a security risk so one solution would be to create a separate user and group, say 'worker' and then spawn the 'player' process as that user.

The specific implementation is as follows :

  • chown the binary (player.out) to the worker user and group chown worker:worker player.out
  • set the SUID bit on it with chmod a+s player.out.
    • this ensures that the process is started with (atleast) it's EUID set to 'worker'.

  • inside the application main use setregid() and setreuid to set the RUID to the same value as the EUID :

    if(setregid(getegid(), getegid()) != 0) {} if(setreuid(geteuid(), geteuid()) != 0) {}

My question is in two parts :

  1. Processes with SUID bit set are usually owned by root and are called setuid-applications to denote (possibly) that their permissions are elevated to root user irrespective of which user invoked the program.
    • is there any special name for binaries that use the SUID bit to automatically drop priveleges?
  2. Is there any other, better way to ensure that the 'player' application drops priveleges?

Edit : I should clarify that I have no control over the "manager" process that spawns the other processes. I only have control over my player application.

Improve this question
1
  • I'd use a wrapper script that does exec su player -c 'exec /path/to/player "$@"' sh "$@" or exec sudo -u player /path/to/player "$@", then you're sure it's done properly (includes setting all the supplementary groups) and you don't have to worry about the permissions of your setuid executable. Commented Feb 19, 2014 at 15:09

2 Answers 2

Reset to default
3

  1. As you correctly state a SUID bit, sets the effective user-id of the new process to the owner of the program file being run. There's no concept of raising or lowering privileges. Often the user to which one "suids" is root, but it can just as legitimately be any other, and doesn't really change the concept of SUID, when you choose another, apart from some users have access to certain resources. However the root user is a little bit special, and the man page for setuid, explains the subtle differences. I don't think there is a special name for changing to a non-root user, and I have never associated suid meaning going up in privilege, just changing user.

  2. Since you are developing the master yourself which runs as root it can setuid to any user after forking but before exec-ing the new process, I dont see that suid bit has to be used on executable at all, and incidently if you don't, then if any-old user ran the player, since executable is not suid, they wouldn't be able to run it correctly since setuid will fail if they were not root. For me this seems like better security, than using suid bits on executable files.

--- edit 1

So your manager (running as real and effective uid=0) starts player and you code/control player (not manager). If you do nothing special, then player will run with real+effective uid=0 and you want to prevent this.

You could just switch uid in player, no SUID bits on player, no need.

Improve this answer
1
  • Sorry, could you clarify what you mean by you're developing the master...? If you mean the "manager" application, i edited to question to convey that the "manager" application code is out of my control. Commented Feb 19, 2014 at 13:59
1

The usual way is that the master process forks, drops capabilities or changes its user ID and then execs the new process.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.