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.
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
