>>>>> "Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> Once they're in the file system, they won't only elevate
Raul> privilege. At that point, programs can be denied privilege
Raul> (even if the user process has the capability, the program
Raul> will drop it).
Raul> In practice, this is mostly useful to keep complex programs
Raul> unprivileged. [It's one of those closing the gate after the
Raul> horses have left kinds of solutions. Better than nothing,
Raul> but not by very much.]
I don't really like this approach, much.
As an example:
I think it would be good, for instance, if the *user* could specify
that only certain programs can have access to ssh-agent for instance.
Giving all programs run by the user ssh-agent access would mean a
Trojan horse could damage more then just files on the local
computer...
However, the policy would depend very much on the users
preferences (which might get awkward). For instance, I could think
of several different policies:
a) only bash gets access to ssh-agent, and its child processes (of
course!). Or even better: only ssh processes executed directly from
bash get access to ssh-agent.
b) only bash, emacs, xemacs, etc.
c) only this copy of bash, running in this X-Window, and all child
processes. This might be appropriate if the ssh-agent has keys that
allow root access to remote accounts. The prompt could be changed to
remind the user that this shell has greater then normal privileges.
This is one thing which currently concerns with capabilities - that
the policy would have to be set by the system administrator/package
maintainer, and not the individual users. As, it is the user who knows
how much he/she trusts each application, what damage it could cause,
and how they plan to use the application.
<dreammode>
Even better, if you could take/remove capabilities to access
individual keys in ssh-agent...
This might be easier to implement with Kerberos tickets, which are
stored as individual files, and not as a separate process.
</dreammode>
Raul> Basically, I see some use for privileges, but I don't want
Raul> to see us going into any kind of "change everything to take
Raul> advantage of this new whiz-bang vaporware" thing.
Perhaps the best solution might be:
- on login give the shell all capabilities for the given end-user.
- allow the shell to deny capabilities, depending on user preference
and/or command line prefix, when starting certain executables.
<dreammode>
eg, thinking aloud:
> deny ssh-agent all
would deny all future processes access to ssh-agent.
> grant ssh-agent --allow-inherent xemacs
would grant xemacs, and child processes access. ie it would override
the previous command, but only for xemacs.
> grant ssh-agent --allow-inherent --execute xemacs
would start a copy of xemacs and with the privilege. Could be simplified
with an alias.
No, whether you consider xemacs a shell or not, and should support
the same thing - I don't care. That can come latter (if at all).
</dreammode>
that way nothing needs to be changed, except:
a) the shell.
b) setuid executables (because the shell wouldn't be able to grant
privileges it doesn't have).
Ideally, the commands would be standardised across every shell, in
such a way that a global config file (or directory) could be used to
setup defaults.
--
Brian May <[EMAIL PROTECTED]>
