DISQUS

time to bleed by Joe Damato: 5 Things You Don’t Know About User IDs That Will Destroy You

  • Eric Wong · 8 months ago
    Process::{GID,UID}.change_privilege changes both effective and
    real user IDs in one fell swoop. This is how Mongrel does it:

    def change_privilege(user, group)
    begin
    uid, gid = Process.euid, Process.egid
    target_uid = Etc.getpwnam(user).uid if user
    target_gid = Etc.getgrnam(group).gid if group

    if uid != target_uid or gid != target_gid
    log "Initiating groups for #{user.inspect}:#{group.inspect}."
    Process.initgroups(user, target_gid)

    log "Changing group to #{group.inspect}."
    Process::GID.change_privilege(target_gid)

    log "Changing user to #{user.inspect}."
    Process::UID.change_privilege(target_uid)
    end
    rescue Errno::EPERM => e
    log "Couldn't change user and group to #{user.inspect}:#{group.inspect}:
    log "Mongrel failed to start."
    exit 1
    end
    end
  • TJIC from SmartFlix · 8 months ago
    Excellent overview - I've been a Unix programmer for 15 years, and some of that was new to me.

    The 8-bytes-of-Ruby was particularly chilling.
  • Khang Toh · 8 months ago
    Did you you submit a patch for starling?
  • Joe Damato · 8 months ago
    @Khang Toh: Yep.
  • Jelle · 8 months ago
    You're wrong about setuid (atleast on linux), see:
    http://linux.die.net/man/2/setuid
    setuid() sets the effective user ID of the current process. If the effective UID of the caller is root, the real UID and saved set-user-ID are also set.
  • Joe Damato · 8 months ago
    @jelle - I probably should have been more clear, but I was referring to the case where you are calling setuid() as root to drop privileges.

    In that case, all 3 IDs are set to the ID passed in.

    Sorry about the confusion, I'll see if I can make it a bit more clear.
  • Chris Gaffney · 8 months ago
    @Khang Toh: Yep, Starling has been patched. We're collecting a couple items before we do the next release.
  • Bibble · 8 months ago
    UNIX UIDs are not as hard to understand as you imagine. Stevens covered it years and years ago.

    If you don't understand how they work you shouldn't run anything as root. If you don't know how to safely drop privileges from UID 0 to some other userm then you don't know how to write secure code.

    Anyone who thinks they can learn secure programming from the odd page here and there of code snippets is mistaken.
  • Cameron Kerr · 8 months ago
    Good coverage, although you didn't make any mention of the added file-system permissions that Linux uses.

    setfsuid(2) etc., credentials(7) and also capabilities(7) are useful manual pages for further exploration for Linux developers.
  • James · 8 months ago
    Stevens was a great author and teacher, but UNIX systems have evolved since then and his books do not apply to many current UNIX systems. To better understand UIDs and security, I recommend Chen's paper "SetUID Demystified" from USENIX Security 2002. It can be found at http://www.eecs.berkeley.edu/~daw/papers/setuid.... Matt Bishop's Writing Safe SetUID Programs at http://nob.cs.ucdavis.edu/bishop/secprog/ is another essential reference.
  • "setuid demystified" is flawed · 7 months ago
    Actually, it turns out that the "setuid demystified" paper was seriously flawed, which is why those guys wrote a followup paper titled "revising setuid demystified" [USENIX ;login 2008], see: http://www.eecs.berkeley.edu/~daw/papers/setuid...

    They also made the code that supposedly safely manipulates identity available here: http://code.google.com/p/change-process-identity/
  • Jesse Farmer · 8 months ago
    Bibble,

    What you said is true but irrelevant. People aren't writing insecure code intentionally, they're writing it because they don't know how these things work!

    The solution isn't to rant and rave about idiot engineers, it's to design systems and libraries that are easy to understand and do the right thing, and make up the difference by educating people.

    That's exactly what Joe is doing.