2

I read from some books that the seteuid together with euid and saved UID can be used to drop root privilege temporarily. The case is:

  1. set euid to a non-root one.
  2. do something which does not require root privilege.
  3. set euid to root again (this works because root is still the saved UID).

I think this is flawed. During step 2, some malicious code could also invoke seteuid to root so this method of dropping root privilege doesn't prevent hijacking code from gain root privilege. Is my analysis correct? If so, what could seteuid-on-saved-UID be used for?

Middleware
  • 330
  • 2
  • 13

2 Answers2

3

Your concern that the malicious code might also restore the effective UID to the saved UID is legitimate. If you are concerned about this, maybe you should not be using a setuid root program in the first place. (LD_PRELOAD and other such things are worrisome in general; they are also restricted when a program is running with setuid privileges.)

Often, though, the mechanism is used in a forked child, where the child will execute some other process without the elevated privileges because the saved UID won't be retained by the executed process. If the malicious code manages to take over before the exec(), then you still have problems. After the exec(), the malicious code only has the privileges of the real UID, and the user could have done whatever it is that the malicious code did.

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
  • Yes. So the seteuid-on-real-uid is useful. But the seteuid-on-saved-uid should be avoided anyway, is it? – Middleware Jan 23 '12 at 23:39
  • 1
    The seteuid-to-saved-uid also has its uses - but should be treated with due caution. I work on a DBMS; (part of) the main server engine runs with root privileges; it uses `seteuid()` to switch between root and 'relevant user ID' and back again to create files on behalf of the relevant user. The relevant user changes depending on whose request it is working on. The cost of fork(), even with COW, is considerable for this system - the DBMS can be using GiB of main (shared) memory, sempahore sets, and you name it. – Jonathan Leffler Jan 23 '12 at 23:45
0

Setuid is flawed in general, because of the possibility of privilege escalation without authentication. Even the notion of root privilege is getting a bit antiquated. Most platforms have updated methods for gaining additional privileges, whether it be from shell with "sudo" on unix and "pfexec" on Solaris, for example.

Additionally they generally have more fine grained controls on which privileges they need escalated. With setuid, its all or none, but with RBAC on Solaris for example, the framework provides methods for specifying which exact privilege(s) you need, generally lower level stuff like opening files, reading directories, etc..

In general, I think now days you should avoid setuid for anything and use newer APIs instead.

creechy
  • 405
  • 2
  • 3