kerberos and setuid

[Nikola Milutinovic]

Awais Sheikh wrote:

> Hello All,
> I am trying to get some clarification on this:
>
> Can kerberos replace the use of setuid kind of applications?
>
> Lets take a case. I need to set my application as setuid root
> because I need to do a privileged operation say bind on a protected port.
> Now inorder to do this, my application owner is root and is has setuid
> bit enabled. As the application runs, effective user id is root, and 
> it binds
> on a particular port and then sets euid to real user id.
>
> Here in order to execute this privileged task of binding on a protected
> port, I had to depend on setuid environment.
>
> How can this work in kerberised environment? Can someone help me
> understand *how* if possible and if not then where is the limit?


It would be possible IF kernel was "kerberized". Whatever properties you 
could lookup on Kerberos or LDAP or PAM or whatever, it still needs to 
be recognized by your kernel. It would also mean that something as 
sensitive as local process privileges would be sourced from outside the 
machine. Think of all the lovely possibilities for hacking or DoS 
attacks. I don't think this is a smart move. SUID is a robust mechanism 
and you will gain no extra security by Kerberizing it - on the contrary. 
This Kerberization will lead to less secure envirnoment.

> I think for me, the missing piece is:
> In order for kernel to allow the bind system call successed, it needs to
> know my existing priviliges(which in kerberised environment could be a 
> special
> ticket to execute bind on protected port), but user-appilication never 
> passed
> that ticket info along with sys-call. That said, I am trying to 
> understand
> if this is possible then how does kernel know all the 
> tickets/privileges a
> user space application has been granted.


You're mixing authentication (Kerberos) and authorization, here. Whether 
or not is kernel going to allow bind call to succeede is not bound to 
your kerberos ticket, but to kernel's point of view. What you're 
envisioning is effectively no different than creating multiple "root" 
accounts (accounts with UID:0). Except that you would like it only for 
bind(). But then you'd want the same functionality for other service 
calls and the story would spread.

This story is generally not a bad one, it is a generalization of ACL 
story and I think Linux kernel has some infrastructure for this, but I 
don't think it is kerberized. In any case, this requires a lot of 
careful thinking and planning, before putting it into the works.

> Is the answer specific to OS. Like if the ans is different for Windows 
> vs.
> Linux/Solaris/HPUX
>
> If the Answer to this is NO.
> Then how about your views "How to eliminate use of setuid?"


Well, SetUID is a simplification of ACLs (Access Control Lists), so, 
let's generalize it back to ACLs. The oposite security infrastructure is 
token-based, where an entity has a token which grants the use of a 
resource - don't mix this with kerberos tickets, they serve only one 
purpose, authentication, while a token can have several access grants.

Nix.