The security on GNU/Hurd is based on authentication tokens. A token is the right for an application to perform a specific set of tasks. Tokens are handled by the ``auth'' server, a server trusted by all other pograms, and enforcing that no one lies on which token they have. Through ``auth'', tokens can be given, destroyed, or created. Tokens can exist for anything, for example you can imagine a token ``is able to bind ports below 1024''.
Tokens are comparable to Kerberos tickets, or POSIX capatibilities.
POSIX compatibility, with regard to authentication, is implemented via specific tokens: UIDs and GIDs are only a kind of tokens that auth can deliver. It is therefore possible for an application to have several UIDs tokens, and as such being able to act with different POSIX identities at the same time. Programs can lose or give UIDs at any time during their execution - they just need to contact auth, and the password server (or any other auth-trusted server that can manage authentication, for example a server that matches a user-given and a sysadmin-provided certificates).
A specific ``addauth'' command (a normal, non-suided program) can give tokens to programs. If you are running a shell as ``kilobug'', you can give the ``UID kilobug'' security token to any currently running application with ``addauth -u kilobug -p [PID]''. The same way, programs can drop their tokens, lowering their permissions.
The translator in charge of a filesystem is the one enforcing the suid-bit. If you run ``/bin/ping'' as a normal user, the ext2fs translator managing the / filesystem will give the root security token to the ping program, before starting it. Since a translator cannot give a security token it doesn't have, a translator ran by a normal user would not be able to enfore the suid-bit, and this way there is no security risk in allowing normal users to run translators.
The password server is a very simple (around 200 code lines) program, which can give UID and GID security tokens in exchange of a login/password pair. A ftp server, or an ssh server, could then run without any permission, and gives the user-provided login/password to the password server, in order to gain privileges and be able to answer to the user. The huge difference with Unix systems is that the ftp or ssh server never has root privileges (or only at bind-time, and then drop it completly), and never has even the privileges of a normal user before someone gives it a valid login/password pair. A flaw inside ftp or ssh would only give a shell with very few rights.
Programs can discard all the security tokens they have and become ``noauth'' programs. This can be used to process untrusted contents, like a ghostscript interpreter running on contents coming from an untrusted source. A security flaw inside the interpreter could not allow a malicious postscript file to damage your own files, since the interpreter discarded the ``UID'' security token before processing the data.